As an enterprise architect we are faced with constructing solutions for our companies that must be implemented quickly but need to scale to almost arbitrary capacity quickly when demand materializes and must stand the test of time because it is almost impossible to rebuild enterprise applications once they are successful and in production.
There are many examples of the history of really successful Enterprise Applications and how they evolved. At TIBCO we had to build several generations of our publish/subscribe technology. Each time we had a major architectural change which reflected our need to scale and interact with more things than the previous generation could possibly handle. Each time we did this was a company “turning point” because a failed attempt could mean the death of the company. So, it is with great pride that during those years we made these transitions successfully. It is a very hard thing to do to build software which is designed and architected so it is flexible enough to adapt to changing technology around it.
Having built many enterprise applications we start with good ideas of how to break things into pieces but after 5 years or more it becomes readily apparent that we broke some things into pieces the wrong way. The book “Zen and the art of Motorcycle Maintenance” discusses how you can look at a motorcycle engine from many vantage points giving you a different way to break down the structure of the engine which gives you different understanding of its workings. This philosophical truth applies to motorcycle engines, string theory and software development. There are always many ways to break a problem down. Depending on your purpose one may work better but it is hard in advance to know which way will work best for problems in the future you have not anticipated.
Todays world of Software development is 10x more productive than the software development of just a decade ago. The use of more powerful languages, DevOps/PaaS, APIs and Container technology such as Docker has revolutionized the world of software development. I call it Platform 3.0.
A key aspect of Platform 3.0 is building reusable services and components. You can think of Services as instances of components. Micro-Services is the idea that we build services to be smaller entities in a lightweight container that are reusable and fast.
Micro-Services and SOA
There is some confusion about the term micro-services. It can be a couple of different things depending on the person using it and their intention. One definition that must be taken seriously is proposed by Martin Fowler:
“The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
Martin goes on to describe micro-services as a way of building software applications as a combination of light weight services (API’s) that are independent. However, IMO this is simply the default way all software is being written today. It is the default architecture for Platform 3.0.
However, micro-services has emerged recently as a counterpoint to SOA type architecture. The idea being that SOA architecture is heavyweight, has intermediate processes that slow things down, increase complexity. Micro-service architecture in some cases is being proposed as a shortcut that means you can build software by simply hardcoding services into your applications and that this is faster and in the long term better than using a SOA type approach of a mediation component or message broker to facilitate agility and best practices.
I have no beef nor concern about services being broken into smaller and smaller pieces that are more and more independent of each other. This is good architecture in general. There is also no beef with the idea micro-services are lightweight and can be replicated and instanced quickly as demand builds. Micro-services can be encapsulated in containers which woven together by a “container orchestration layer” allows one to specify how the micro-services are handled in fault tolerant and in scaling up and scaling down. The orchestration does not have to become an intermediary process or communications layer that slows anything down.
Many of the principles of SOA have to do with agility to know what applications and services use what other applications and services. This facilitates being able to change those dependencies quickly and reliably in an enterprise situation. These concerns are not lessened but magnified because of a micro-services architecture.
Another definition of Micro-Services
Over the last 5 years APIs have grown dramatically in popularity and importance. These are the “services” that are being reused in Platform 3.0 around the world in applications for mobile devices and in enterprises. These API services are becoming ubiquitous and driving enormous innovation and growth. See my article on 10^16 API calls.
What has evolved is that these APIs are becoming heavier and heavier weight as naturally happens with success. As vendors get more customers with more diverse needs the APIs become bulkier and more powerful. This is the standard evolution of software.
A counter to this is Micro-services. The idea is that APIs should be leaner and that getting the functionality you want should come from a variety of smaller APIs that each serve a particular function. In order to facilitate efficient operation of applications that utilize micro-services as opposed to the larger “API services” concessions have to be made to the overhead associated with invoking a micro-service.
Netflix is one of the major proponents of this idea of Micro-services. Netflix has been learning as it builds its enormous presence in the cloud that breaking its offerings into more and more independent services each of which is ultra efficient and easily instanced is the architecture that works best. They are even challenging one of the most powerful concepts of the last 10 years in APIs that APIs should be RESTful. They suggest that “simpler” protocols with less overhead work better in many situations and actually trying to convince people REST is not the end of the story for APIs. Paradoxically, REST is promoted because of its simplicity compared to SOAP for instance.
The advantage of micro-services according to the Netflix definition is that services can be more rapidly scaled and de-scaled because they are so lightweight. Also, the overhead associated with conformance with heavy protocols like HTTP is not worth it for micro-services. They need to be able to communicate on a more succinct, purpose driven approach. Another advantage of the Netflix approach is to be able to short-circuit unavailable services quicker. Please see the article on Chaos Monkey and Circuit Breakers.
In a similar way with the first definition of Micro-services breaking down these services into hyper small entities doesn’t mean that they are not still containerized and the interface to them documented and managed albeit in a less obtrusive way than some API management approaches would entail. If you look at the commandments from the Netflix development paradigm it includes key aspects of good SOA practices and API Management concepts.
API Management and MicroServices
API management is in my mind is simply an evolution of SOA registration service with many additional important capabilities, most important SOCIAL capabilities that enable widespread reuse and transparency. If the goal of micro-services is to avoid transparency or social capabilities I would have serious argument with the micro-services approach. As I mention above Netflix’s approach doesn’t suggest API Management is defunct for a micro-services architecture.
Part of the problem with API management and micro-services or with the mediation / message broker middleware technologies is that these can impose a software layer that is burdensome on the micro-services architecture. In the case of the mediation / message broker paradigm this layer if placed between two communicating parties can seriously impede performance (either latency or overall throughput) especially if it isn’t architected well. In fact this layer could make the entire benefit of micro-services architecture become a negative potentially.
Let us say an approach to implementing micro-services would be to put them into a traditional API Management service as offered by a number of vendors. There would indeed be an overhead introduced because the API Layers impose a stiff penalty of authentication, authorization, then load balancing before a message can be delivered. What is needed is a lightweight version of API Management for some trusted services behind a firewall that are low risk and high performance. The only vendor I know that offers such a capability is WSO2.
WSO2 implements all its interfaces to all its products in API management as default. The philosophy is called API Everywhere and enables you to see and manage all services, even micro-services in your architecture with an API Management layer. You can choose during debug phase to impose a higher burden API management that gives more logging of what is happening to help you understand potential issues with a component or micro-service and to monitor performance and other characteristics more closely and when you are satisfied something is production worthy to go to a minimal in-process gateway that minimizes the impact on performance but still gives you some API Management best practices.
Other SOA components and Micro-services
Other components in the SOA architecture are mediation services and message brokers. These components are used to provide agility by allowing you to easily change components in and out, version components or services, create integration with new services without having to change applications and other benefits. These are still important in any enterprise application world and are particularly important in the fast changing world of Platform 3.0 we live in today where services change rapidly and applications are built using existing services rapidly.
One of the primary goals of the SOA architectural components was to facilitate the eradication of the productivity killing “
point-to-point architecture that made “the pile” of become impossibly
hard to whittle down.
More important than that is the lesson we have learned in the last 10 years which is that social is a critical component of reuse. In order to facilitate reuse we must have transparency and the ability to track performance, usage of each component and have feedback in order to create the trust to reuse. If the result of micro-services is to destroy transparency or some ability to track usage and performance then I would be against micro-services.
I believe the answer is in some cases to use API management traditionally and in some cases to use container orchestration services such as Kubernetes, Docker swarm and Docker Compose, Helios and other composition services. I will be writing about these container composition services as they are an important part of the new architecture of Platform 3.0.
Summary
Micro-services is the new terminology being espoused as the replacement architecture for everything from SOA to REST. However, the concepts of micro-services are well founded in reuse and componentization and as long as good architectural practices from the lessons learned in the last 2 decades of programming are followed and implemented inside a framework of Platform 3.0 then micro-services is a good thing and a good way to build applications.
Micro-services provides an easier to scale, more efficient and more stable infrastructure in principle. Micro-services once written are less likely to see lots of modifications over time as their functionality is constrained. This means fewer bugs, more reusability and more agility.
Micro-services however should still be implemented in an API Management framework and ESB’s, Message Brokers and other SOA architectural components still make sense in this micro-services world especially when augmented with a container composition tool. In fact these components should be used to make micro-services transparent and reusable.
CloudRamblings 
Thank you for inspiration – “Architecting #cloud-friendly application architecture & #microservices” – https://www.linkedin.com/pulse/architecting-cloud-friendly-application-architecture-samarin
Thanks,
AS
LikeLike