Microservices is the new buzzword in IT. Though the concept is not new, it can be an enabler for improving your IT delivery process. In a series of blog posts, we want to explain how Microservices can kick-start Agile Software Development, Continuous Delivery and Service Oriented Architecture. But before we take you on this journey, let’s start with some old-fashioned software development.
The Good-Old Approach to Software
The most natural way to create an application is to build it as one single unit of code: a so-called Monolithic Architecture. Even though Enterprise Applications are usually built in three layers (or ‘tiers’), they are still monolithic. They will have a (often browser-based) user interface and data is stored in a relational database, but the server-side application is still a monolith, one piece of code.
There are downsides to this architecture. Because the application is a single unit, a single functionality change has impact on the whole application. You need to regression test everything and the whole application has to be (re)deployed, often meaning downtime. Scaling is another challenge. Spreading load over multiple instances of the application (‘scaling out’) might not be possible at all, as this capability was not built in from the start.
Enter: Microservices
As this frustrated people, the Microservice Architecture evolved. Applications are built as a collection (or suite) of services. Services are developed independently, allowing them to be deployed independently. In what we consider one of the best (if not the best) articles on the topic, Martin Fowler describes Microservices Architecture; we’ll summarize below.
Componentization via Services
Just like in machines, it makes sense to build software in components. Microservices Architecture sees services as individual components that can be individually developed and replaced, just like in your car. No need to replace the whole thing when you can replace the component.
Organized around Business Capabilities
Microservices are organized around business capabilities, not around technical capabilities. So we do not have separate user interface-, database- and middleware-teams, but cross-functional teams, e.g. a Telecoms Fulfillment team.
Products not Projects
Microservices are project-agnostic, i.e. they provide business capabilities (e.g. ‘lookUpCustomer’) instead of providing project-specific functionality. This enables re-use of services and thus reduces costs.
Smart Endpoints, Dumb Pipes
Communication between components is often made quite complex, using Enterprise Service Bus functionalities like intelligent message routing and message transformation. In Microservices, this type of logic is in the component, keeping the message bus simple.
Decentralized Governance
Enterprise Architectures tend to be prescriptive about technology platforms and standards to use. But like in life, you only want to use the tools you need. An electrician doesn’t need an axe. In Microservices Architecture, the approach is to use tools as they’re needed and let it evolve into a set of tools and standards.
Decentralized Data Management
As mentioned, Enterprise Applications tend to be three-tier, with the data in a central database. Applications have their own view on the data. In Microservices Architecture, each component manages its own data. Though companies need measures to prevent data inconsistency, this approach simplifies data management and by that: costs.
Infrastructure Automation
Because Microservices are small, separate components, it’s easier to automatically test, and less risky to deploy changes. This opens the door to Continuous Delivery, enabling a quicker time-to-market with less costs and risks.
Design for failure
When you build Microservices, your applications need to be able to tolerate failure. After all, a service can be unavailable. As paradoxical as it sounds, this in fact makes your whole architecture more robust. Murphy can’t hit you when you anticipate he’s around there somewhere.
Evolutionary Design
When breaking down an originally monolithic application into components (Microservices), start with the parts of your application used or changed most often. As this is an iterative process, the design should change or ‘evolve’ as well.
What Microservices can teach us
Microservices Architecture is a good place to start your Integration Layer design principles, giving you tremendous opportunities to continuously deliver robust software with great business value.
In our next posts we will dive into the benefits of Microservices Architecture for Agile Software Development, Continuous Delivery and Service Oriented Architecture. More to come, stay tuned!
