This is a perfect opportunity for us to explore cloud serverless offerings as the ultimate contact-less development option. While COVID-19 continues to make face-to-face collaboration an impossibility, cloud-based applications and workloads provide a well-defined method for remote development and project deployment. Serverless offerings, like Azure Functions and Azure Logic Apps, take this to the next level while allowing us, as developers, to focus only on our application functionality and not the backing infrastructure or uptime of servers. These serverless solutions will be the focus of this blog.
Microservices? Yeah, you’re doing it wrong.
Microservices is a silver bullet, magic pill, instant fix, and can’t-go-wrong solution to all of software’s problems. In fact, as soon you implement even the basics of microservices all of your dreams come true; you will triple productivity, reach your ideal weight, land your dream job, win the lottery 10 times, and be able to fly, clearly.
While this sounds like a lot of hyperbole wrapped up in some BS, if you have been listening to anything around microservices recently you will most likely have heard something not too far from this exaggerated sentiment – especially if it is coming from sales folks.
As a result of this, you or someone you know will likely have been charged by management to implement a solution in microservices or refactor an existing application to take advantage of microservices to ensure that you get all the magic. With so much overinflation of the truth out there, chances are you may have also implemented a microservices antipattern. These antipatterns are actually more common in the wild than fully functional microservices architectures.
In this post we will cover the most common antipatterns that I have witnessed in the wild:
Break the Piggy Bank
Everything Micro (Except for the Data)
We are Agile! a.k.a. The Frankenstein
Each one of these results from a common misconception. We will do our best to define these patterns and their symptoms. After each, we will also show a way out of the mess so that you can recover and begin to move towards a better implementation. Let’s get started!
With the evolution of microservices and the scalable nature of modern distributed architectures, batch processing seems to be falling out of favor. In fact, the term batch processing itself seems to be unfavorably associated with monolithic mainframe applications and thus does not seem to have much appeal.
Unless, of course, you are working on a project that is being designed to replace or modernize one of those mainframe applications. If that is the case, then likely some sort of batch process has come up with a non-functional requirement that needs to be dealt with in the new system.
For this specific concern, a very powerful framework has been provided: Spring Batch. It has many of the same features of a mainframe batch process like restart/recovery, chunk processing, and error handling along with exit codes. This framework allows developers to create powerful batch processing applications in the Spring Framework and enjoy the rich backplane of capabilities that this provides.
Continuing with the modernization thread, you will likely be tasked with providing some assurances to the business that the new, modernized process will produce the same outcome as the one that is being replaced. Here is where testing comes in, and where Cucumber specifically shines.
Cucumber provides behavioral testing support in the Spring universe. This allows developers and business users to collaborate through a common set of conventions and verbiage to validate that the app is behaving how the business intended as well as how the developer coded it.
In this post we will cover the following:
Why use Cucumber with Spring Batch
An overview of Cucumber and an example Cucumber Test
How to start with Cucumber and Spring Batch…
We have consultants who specialize in moving old to new, renovating dilapidated code bases, and designing brighter futures for enterprises who have been vendor-locked for most of their existence. We have come across some repeated patterns and strategies for how to approach modernization of legacy systems. In this blog, we will cover a strategy that is very popular right now, Re-Platforming.
The basic flow of this post will be:
Introduction to Modernization
High-level definition of the Re-Platforming Strategy for Modernization
Sample of Re-Platforming using Keyhole Syntax Tree Transformer, COBOL –> Java
Additional thoughts on the value/risk of this strategy
Let’s get started…
Attention: The following article was published over 5 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.Your application just launched into production after 6+ months of development and bug fixes. In true Agile fashion, you and the team released your MVP (minimal viable product). You did your best …