Microservices Part 1: The Legos for your Cloud Adoption
Lead with Speed and agility using Microservices
We all love Legos, don’t we? I have always been curious how these tiny blocks when assembled in the right way can build massive architectures and even stunning replicas of cities and monuments.
Just like Legos, Microservices are the building blocks that help in decoupling massive enterprise solutions into smaller blocks and assemble them based on demand and scale.
Microservices architecture is the foundation to help your business, build and support future cloud services, innovate faster and increase business agility. Adoption of microservices patterns (or microservices based architecture, so to speak) has been the trend in the last few years for organizations that embrace the API economy and those that drive digital transformation within their organizations. Among the first pioneers were the companies operating at internet scale such as Amazon, Google, Netflix who re-architected their platforms around microservice based architecture to better serve their customers.
Since then the trend has caught on as organizations have understood the benefits of a microservices based architecture. Enterprises have started adopting a microservices based approach whenever they modernize their legacy systems or undergo a digital transformation, or when they embrace the API economy to drive new channels of growth. As more technology startups continue to disrupt established enterprises, the microservices trend is only likely to grow in the coming years.
What are Microservices?
Let’s start by looking at what really constitutes a microservice. A microservice is an independently deployable service that serves a single and clearly scoped business purpose or capability. It consists of a logical element that implements the business purpose in a bounded context, an out-of-process or externally invoke-able interfaces such as a web service request or remote procedure call, and an interface definition often defined via an API contract.
Why do we need Microservices?
Traditionally, enterprise IT systems were built as monolithic applications organized around the 3-tier architecture pattern — a client user interface, a server-side application for the business logic and a database to serve the server application. As these monolithic applications became complex, even small incremental changes to the application required extensive validation, system testing, and scheduled downtimes during deployments. This is where microservices architecture patterns have served to address the pain as they are organized around business capabilities unlike traditional monolithic approach, where specialized teams cater to one of the 3 tiers – UI, server-side and database. Microservices architecture is organized around cross-functional teams where each team is responsible for the bounded business capability that the microservice fulfills.
With changing consumer habits and expectations, it has become imperative for enterprises to cater to the evolving consumer tastes in a much more nimble, reliable, and faster manner. Traditionally, many of these enterprise projects were developed and managed by Central IT, where the IT team delivered projects based on business requirements for the whole company. For instance, an end-to-end Order to cash project was built conventionally where the IT team leveraged a monolithic ESB technology and built business logic around it. Such projects were often slow to build, hard to manage, and came with heavy operational and maintenance overhead. This has resulted in the adoption of microservices at scale as enterprises adapt to providing experiences across multiple channels such as mobile, web, social, etc.
Avoid the top 7 pitfalls
There is a popular running joke that your hammer will always find nails to hit. Likewise, once you have adopted microservices architecture, it can be tempting to turn everything into a microservice. As a result, you might end up with a plethora of microservices, some of them with high coupling and dependencies that become hard to manage in the longer term. To preempt such architectural mistakes, it is important to be aware of some common pitfalls. Some of the most common ones are highlighted below:
- Splitting highly coupled systems: It can be tempting to split services into many distinct microservices. Avoid splitting services that are highly coupled and have integrated functionality.
- Development complexity: As the number of microservices proliferate, it becomes harder for developers to understand the interdependencies and run the required services to test their features on their machines. Use proper orchestration tools and/or integration platforms which take care of these development complexities.
- Language proliferation: Microservices enables decoupling of services. Thus, developers might be tempted to use languages that they are most comfortable with to develop their service. As a result, you could end up maintaining multiple languages and frameworks. That said, you should not put artificial constraints. An optimal balance needs to be struck so as to enable innovation at a faster pace while also ensuring you maintainability of the code base. Where possible, use an integration platform that abstracts away complexity but also provides cross-platform and multiple languages support
- Non-uniform SDLC processes: With decoupling of services, comes flexibility to plan, develop, and maintain different release cycles for each of these services. While independent release cycles and deployments are great, make sure standard SDLC processes are followed across all microservices so as to ensure software quality, proper release cadence and processes.
- Low discoverability: As your systems start consuming lots of microservices, it is important to manage, maintain, have contracts and visibility across these microservices. Otherwise, no one would have visibility into the numerous microservices and it becomes very hard to discover, debug, plan, and manage the complexity that arises from the promulgation of these services. Invest in an integration platform when your system consumes lots of microservices.
- Weakest link: As the number of microservices increases, it becomes important to ensure they all have good SLAs and up times. The whole system must be scalable to meet these goals, otherwise, your system is only as good as the microservice with the poorest SLA and scalability.
- Incompatible Deployments: To fully leverage the value of microservices, you need to create and maintain multiple environments (Dev, Test, Prod) along with mature DevOps processes to deploy, manage, and monitor microservices. Without separate environments, developers could end up deploying and testing different and/or incompatible versions of their microservices resulting in slowing down the software releases and reduced efficacy.
Designing for success and scale
Although it is possible to design your microservices from the ground up and deploy, manage and monitor them on infrastructure-as-a-service platforms, if not managed properly, the microservices could soon become hard to manage and govern. Soon enough, you would end up dealing with some of the manageability, scalability, visibility, and deployment issues highlighted earlier. Then, there is time-to-market, technical expertise and cost aspects that needs to be taken into consideration. Ultimately, instead of expediting delivery it could slow down your delivery velocity.
A faster, efficient, more manageable, and inexpensive approach from a Total Cost of Ownership perspective would be to use an iPaaS platform (integration-Platform-as-a-service) that supports all your application needs, integration patterns, and provides the flexibility to manage and deploy your microservices anywhere without the operational overhead of managing the infrastructure yourselves. Mature iPaaS platforms not only provide a system view into your business needs but also provides a holistic framework to build and maintain microservices based architectures.
Modern platforms also foster collaboration between different departments and teams with different business requirements such as integration, master data management, governance, and security by providing a unified and complete view of microservices and its dependencies.
Many enterprises have traditional ERP systems and on-premises databases that need to be integrated with SaaS applications. Data needs to be governed, moved, and transformed from multiple systems across cloud and hybrid environments to arrive at a system of record that provides a consistent view of the business.
Changing business trends mandate enterprises process data and generate insights at the speed of the business. A one-size-fits-all approach that is confined to either bulk data movements or just real-time data movements alone will fail to support the varying use cases and business needs.
While there are numerous cloud integration platforms aka iPaaS to choose from to make your project a success, make sure you settle on the iPaaS platform for the right and relevant reasons that apply to your data-driven digital transformation strategies — and not just your immediate needs.
Stay tuned to learn more in part 2, where I will share the key factors to consider when selecting an iPaaS platform as your IT’s Lego foundation and how you can accelerate your business outcomes leveraging microservices.