Update December 2017: TMNS is now Devoteam
Your DevOps teams are working in sprints following SCRUM methodology. You have continuous integration (CI) and continuous delivery (CD) process in place. You are able to release your changes quickly. Your application is not a monolith, but a collection of reusable loosely coupled components. Each component can be deployed and upgraded independently. Your workload is predictable and constant. Your platform is highly available and scalable. What can you gain from adopting MSA and is it worth the effort?
According to Martin Fowler: “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
In addition, Martin gives the following list of common Microservice Architecture characteristics:
- Componentization via Services
- Organized around Business Capabilities
- Products not Projects
- Smart endpoints and dumb pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for failure
- Evolutionary Design
How exactly we achieve those characteristics, we may not agree on. IT community is a free community and we like to have our own opinion. But if we compare those characteristics with characteristics of Service Oriented Architecture, more or less they are very similar if not the same. Actually most that we do in Microservice Architecture is not necessary new, but we have better ideas and better tools for doing it. We have learned from doing SOA more than 10 years. We have gained experience and now we want to do it in a better way. Technology has also evolved over the past years and we see more and more open source tools emerging in the domain previously dominated exclusively by big vendors. And this is exactly where we have to search for benefits of applying this new architecture style.
Adoption of software container platforms like Docker and distributed streaming platforms like Apache Kafka, can help companies reducing operational and license costs significantly. Biggest downside of successful SOA implementations is that they are all vendor dependent. SOA implementations are in general tightly bounded to expensive middleware solutions. Some vendors even tend to design specialized hardware for their middleware platforms which makes a SOA implementation even more expensive and creates a high operational cost. SOA silos are already becoming too complex and many vendors already suffer from it.
Microservice architecture very much address this problem. And this is a very specific aspect of MSA style compare it with SOA, where we were used to run our application in a single highly available, scalable, cluster environment. This environment is part of enterprise infrastructure and operational teams are responsible for maintaining it. With microservices this platform becomes DevOps team responsibility. Team takes ownership on a set of functionalities, set of features. It’s theirs! Not only to develop but also to deploy and run. They build it, they run it, they fix, they evolve it! They go through the entire life cycle including operations. And in order to be responsible for the operations of your microservice, you need to be able to take complete control over the platform on which your microservice is running. This MSA characteristic opens a new world of possibility where we design light-weight environments to support our microservice and each microservice will have its own specialized environment supporting only functionality needed by that particular microservice. Flexibility that we gain with this approach is huge! We can choose and pick any available technology from the market and combine them in a way that we think is best for our microservice, avoiding usage of shared environments which are to heavy and expensive to be dedicated to a single microservice.
For now I want to focus on this aspect of MSA, from which I think that a successful SOA implementation can benefit most. With a series of articles I want to document our journey of building an open source MSA platform. This new platform needs to support all functionalities previously provided by expensive SOA middleware solutions and it needs to be fully open source.
So how are we going to do it?
Even more decoupled! Decoupled not only on the functional level, using service interfaces and API’s but also non-functionally. Not having our services sharing the same platform in which heavy load on one service takes down other services as well. Stateless is something we really aim for and we didn’t do so in the past. We did state! Which means we can’t easily scale out, we can’t easily transfer sessions from one node to other nodes. Standalone in terms of deploy, management, scale. Asynchronous, SOA typically resulted in the exposure of synchronous web services such as SOAP/HTTP. In microservices, a synchronous protocol such as HTTP, whether SOAP or REST based causes a real-time dependency between components, so messaging is the preferred transport between microservices wherever possible. There’s more too, for example with issues relating to service discovery, and data duplication and more. But let’s first list all functionalities that are provided by a SOA middleware platform and which we want to have in our new MSA platform as well:
Service Discovery
We have to work with plenty of different independent microservices and a huge number of distributed instances of each microservice. An internal service discovery framework is needed to locate services for the purpose of load balancing and failover. Therefore a service provider registers to the registry when it is available. Consumers discover the service from the registry to be able to connect and consume it.
Infrastructure management
An infrastructure manager is needed for failover and high scalability. Evolution of software container platforms helps us to build agile software delivery pipelines to ship new features faster, more securely and with confidence. Container platform is used to automatically orchestrate container scheduling and managing hosts including the application of rules and constraints to each host.
Load balancing: needs to become much more sophisticated (and therefore complex) with microservices and containers. Just distributing load based on well-known IP addresses and hosts is not sufficient anymore. Concepts such as weighted load balancing based on several factors like traffic, resource usage or error conditions provide superior resiliency.
ESB
Service Bus is still needed. But not the complex, central and heavyweight beast you might think of. This might have been true 5 to 10 years ago (and one of the reasons several SOA projects failed that time) and it might still be true for some vendors today. But in general (and valid for many vendors) an Enterprise Service Bus in 2017 is a mature, stable and easy to use component, which should offer:
- Integration
- Orchestration and Choreography
- APIs and Business Services
- Messaging
- Independent Deployments
- Scalable and Lightweight Platform
- Automation
Next: New landscape and exploring all microservice concepts
Based on all mentioned above we can start drawing a new landscape and exploring all microservice concepts from first hand. But we will be careful as this new platform should be manageable and doable and we will probably need automation to make it efficient and quick enough and we should not make it too difficult.
Finally, I would like to quote Martin Fowler once more: “there is the factor of team skill. New techniques tend to be adopted by more skillful teams. But a technique that is more effective for a more skillful team isn’t necessarily going to work for less skillful teams. We’ve seen plenty of cases of less skillful teams building messy monolithic architectures, but it takes time to see what happens when this kind of mess occurs with microservices. A poor team will always create a poor system – it’s very hard to tell if microservices reduce the mess in this case or make it worse.”
