Microservices: Built for Speed, Design for Change
Microservices: Built for Speed, Design for Change
Let's talk about how a modular approach prepares you for uncertainty, gets your product into the market, and can company into a great place to work!
Join the DZone community and get the full member experience.Join For Free
In a world made of software, it's no longer just an IT decision on how we build applications. Let's talk about how a modular approach prepares you for a world of uncertainty, gets your product out into the market faster-and may even turn your company into a great place to work!
Speak to your IT Architect about Microservices and they may patiently explain to you how this architectural style for systems involves every logical function of an application running as a dedicated service, scaling individually and using standardized contracts for efficient communication with one another.
And in fact, it's one of the big topics today that developers, architects, integration specialists, and IT operations are looking at currently for creating modern applications, as well as making legacy systems manageable for today's requirements. Yet, the implications and benefits for the company go beyond pure technical or operational aspects and touch the substance and organizational structure of modern, competitive companies.
Breaking Down the Monolith
A couple of years ago, I found this illustration that beautifully captures the essence of distributed systems: the blue whale and the school of fish. Without having to be a technical expert, one could almost immediately recognize the nature of monolithic applications, technical or organizational, and the benefits of a system where the functions of that huge mammal are broken down into many small and redundant parts without a single point of failure.
Now, let's assume the business logic of the software you're using at your company is broken down into smaller portions in a similar fashion. These can be developed by individuals or small teams, where they use the best tool, programming language, or framework for that particular job. The services can then be tested, deployed, and scaled independently-and ultimately available in a catalog of building blocks that developers can put together for a new project.
Design for Change
One of the obvious results is speed: delivering new products and features a lot faster. But that is just the surface. Well implemented, well documented independent services allow much more efficient resource planning in terms of development time, hardware, and the number of developers needed for the individual tasks.
Speaking of developers: they will most likely take less time getting up to speed getting familiar with the building block they're working on-and rapidly consume other pieces where they only need to understand the interface without the underlying complexity. Ultimately, by adding automation into the picture we get repeatability when it comes to scaling your offering and recovering from system failures.
So, breaking up the big problem into many small ones gives us speed as one of the major benefits. The other area is something I've intuitively felt for quite some time now but only found it articulated powerfully when watching Eyal Sivan's keynote at the Axway Sales Kick Off in Montreal earlier this year. The metaphors of systems design are changing from things like "city planning" where you need to get the design right before you start building-towards biological systems that can evolve, adapt over time, and are built for change.
If we had a vague idea last year about living in an age of uncertainty, we know it for sure in 2020. Some companies and public sector organizations only took a week or two to build solutions that address the current challenges, and it's because they make use of modular concepts like we discussed.
It's a good time for introducing change. It always is, but particularly right now when the planes are on the ground and we can inspect the engines a little longer, and realize the planes need a major overhaul. Get started on that journey there is no return.
Things do get more complex as we look at this from a technical perspective. Microservices, Service Mesh, APIs, and many more are different approaches to find the best balance between agility and manageability.
Join us for the third webinar of our "Around the Corner" series with a discussion about APIs on the Edge-Gateways and Service Mesh. This is a deep, technical session together with Axway architects John Wiese from Professional Services and Mihir Mone from Sales Engineering where we speak about API Gateway deployment patterns for securing and routing traffic in microservices and mesh architectures.
With an evolving application design, these individual components generate significant amounts of "east-west" traffic that needs to be managed as well. The conversation will cover use cases, the right fit for customer environments, and which pieces of existing API infrastructure can be leveraged for unified governance and developer experience. Learn more about the Catalysts and how they can take your company further here.
Published at DZone with permission of Uli Hitzel . See the original article here.
Opinions expressed by DZone contributors are their own.