Want to read more on the process of migrating to microservices? Read the full eBook on “How to Build (and Scale) with Microservices” here!
Today, modern enterprise is rushing head first into an always-on, digital-centric, mobile world. Organizations that fail to modify their approach to technology will be left by the wayside as others incorporate highly flexible and scalable architectures that adapt quickly and efficiently to the demands of the modern marketplace.
The rapid rise in popularity of microservices was driven by these market influences. In just a few short years, companies have implemented various configurations of technologies to offer the best user experience.
Challenges with Migrating
One of the primary challenges when considering migrating to microservices is that monolithic legacy systems cannot be changed overnight. DevOps and IT managers must decide where and when they can incorporate microservices into their existing applications. In the “Four-Tier Engagement Platform” for Forrester Research, Ted Schadler, Michael Facemire, and John McCarthy say it is time to move the technology industry to a four-tier architecture.
In an article for Infoworld, Patrick Nommensen summarized the Four-Tier Architecture. As he explains, the dramatic changes in computing, including the incredible market penetration of mobile devices, means developers must take an entirely new approach to thinking about application development. The Four-Tier approach is broken down into different layers:
- Client Tier: The delivery of customer experience through mobile clients and the Internet of Things.
- Delivery Tier: Optimizes user experience by device while personalizing content by monitoring user actions.
- Aggregation Tier: Aggregates data from the services tier while performing data protocol translation.
- Services Tier: The portfolio of external services such as Twilio and Box, as well as existing data, services, and record systems already in-house.
Perhaps the biggest difference with this new approach is the separation of the client tier. With this model, the layers underneath are constantly changing based on real-time interaction with users.
A Practical Approach to Migration
So what tools do you need to move into microservices? The first consideration is that you must decide on a microservices architecture. Figure out how the services will interact before trying to optimize their implementation. Next, while microservices architectures provide much speed, you have to continually optimize those speed gains. This means that you have to be flexible in the tools that you use to deploy the architecture.
Owen Garret shares with InfoWorld a practical, three-step approach to handle a migration to microservices:
- Componentize: Choose a component from your existing applications, and create a microservices implementation on a pilot basis.
- Collaborate: Share the techniques and lessons learned from the pilot in Stage One with all stakeholders, programmers, and developers on the team. This gets them on board with new processes and initiatives.
- Connect: Complete the application and connect to users in a real-world scenario.
Data Coupling
Microservices architecture is loosely coupled with data often communicated through APIs. It is not unusual for one microservice to have less than a couple of hundred lines of code and manage a single task. Loose coupling relies on three things:
- Limited scope and focused intelligence built-in.
- Intelligence set apart from the messaging function.
- Tolerance for a wide variety of modifications of microservices with similar functions — changes are not forced or coordinated.
The APIs translate a specification that creates a contract which indicates what service is provided and how other programs are supposed to use it. Using APIs to decouple services creates a tremendous amount of freedom and flexibility.
New Service Platforms
Platforms for microservices are evolving rapidly. New platforms are emerging while more established platforms are modifying their approach. Some examples include:
- Microsoft’s Azure BizTalk Microservices lets clients using Azure build microservices applications in their choice of cloud. It is part of a greater effort to move Azure to a model of small components.
- Gilliam is a Platform as a Service (PaaS) custom made for creating, deploying and scaling microservices. It creates a Docker image of every code repository onsite.
- LSQ is a PaaS with pre-made templates, documentation editor, and NPM package manager. It includes a development environment, assembly and testing area, and cloud deployment.
- Pivotal is a native cloud platform that focuses on developing microservices for companies like Ford, Allstate, Mercedes Benz, GE, Humana, and Comcast.
Microservices to Help Legacy Apps
Consider a legacy system coded in C and running on multiple mainframes. It’s been running for years without any major hiccups and delivers the core competency of the business reliably. Should you attempt to rewrite the code to accommodate new features? A gradual approach is recommended because new microservices can be tested quickly without interrupting the reliability of the current monolithic structure. You can easily use microservices to create new features through the legacy API. Another approach is to modularize the monolithic architecture so that it can still share code and deployments, but move modules into microservices independently if needed.
People and Processes
Deploying microservices involves more than incorporating new technology. You have to be able to adopt new processes and team dynamics to make the transition effective over time. Oftentimes managers break applications down by technology, assigning responsibility to different teams. With microservices, applications are separated into services that are grouped by business capability. All software such as user experience, external connections, and storage are implemented within each business domain. Team members handle full application development from user interfaces down to databases.
This change in structure affect the people within it too. Developers used to monolithic systems may have a difficult time switching from a world of one language to a multi-language land of new technologies. Microservices frees them up to be more autonomous and responsible for the “big picture.”
However, operating in this new found freedom can be overwhelming for programmers with years of experience in the old ways of doing things. You must be constantly aware of your team’s ability to change. They may need time to adjust to new guidelines and procedures. Clear communication is the key. Detail their responsibilities in this new style of working and why they are important. Unless you have buy-in from your team members at the start, making adjustments later may be difficult at best and dead on arrival at worst.
Entering the New Era of Computing
This new era of computing is based on ultra-fast data processing. Events are monitored, analyzed and processed as they happen. We can make timely decisions based on this continually updated flow of data, resulting in better service for clients, improved operations and instant monitoring of business performance against predetermined targets.
Microservices are not a panacea. There are potential drawbacks such as code duplication, mismatch of interfaces, operations overhead and the challenge of continuous testing of multiple systems. However, the benefits of creating loosely coupled components by independent teams using a variety of languages and tools far outweigh the disadvantages. In our current computing environment, speed and flexibility are the keys to success — microservices deliver both.
Want to read more on the process of migrating to microservices? Read the full eBook on “How to Build (and Scale) with Microservices” here!
