How to plan a microservices implementation
Back in the early days of enterprise technology, which was when I last did any significant application development work, it would take weeks to design and build even relatively simple applications. If you were lucky, someone else in the organization or a vendor had a code library or two that you could acquire and compile into your application. This required deep technical knowledge of the underlying code.
If you've done any recent development work -- and I strongly encourage IT leaders to occasionally do a 'Hello world'-type application to understand modern tools -- you've probably been amazed that most of the work is around integrating various services. These services can be accessed over public networks, and use standards like JavaScript Object Notation (JSON) to exchange information in a way that anything from a mobile app to an enterprise application can process. Developers no longer need to understand any of the underlying complexities of how the service works, allowing amazing functionality with minimal complexity.
The possibilities become obvious rather quickly. Complex integrations are the 'black hole' that derails many well-intentioned development projects, so if they can become simplified and de-risked then custom apps that create unique advantages for your company are no longer an option of last resort. This, of course, requires that your internal systems have a microservices layer that allows key functionality from company systems to be delivered through standardized services.
While this may seem like a daunting task, these standardized interfaces would be designed to accomplish a single, discrete task, hence the 'micro' in microservice. In traditional systems design, you might pass data to another application that 'takes over' the remainder of the transaction. In a microservice environment, the application acts like a conductor, coordinating a function by asking hundreds of different services to perform a discrete task that's independent of the larger transaction.
The magic of microservices
Amazon is perhaps the best example of scaling microservices across the organization. While it seems a distant memory, 15 years ago you would have been laughed out of the room for suggesting Amazon would become a dominant IT services provider. The now-unquestioned dominance of Amazon Web Services (AWS) started with a simple mandate that every computing service Amazon used internally be created as a microservice.
Amazon quickly realized that with all of its systems providing simple, common, and stable microservices, other parts of the company, and ultimately the public at large, could use these services quickly to create their own applications. Amazon, and later AWS customers around the world, were freed from the vagaries of version upgrades, system changes, and code updates, since they could always depend on a service producing a consistent result, irrespective of the technology used to provide that result.
Transitioning to microservices
For starters, duplicate Amazon's move and mandate that all new software projects be delivered through microservices. If that's too challenging, it may be easier to start more simply. Probably the best place to do that is when acquiring new software or platforms. This is easy when buying cloud software as a service, as most providers deliver a suite of prebuilt microservices to interact with the data and business logic.
Identify some simple use cases that show the benefit of microservices. For example, if you implement a cloud-based sales platform, you might leverage microservices to capture data on your website and feed it into the sales system. Or, you might quickly develop a mobile or web-based app in record time that performs a specific, meaningful task and demonstrates that microservices make IT faster and more flexible. Rather than focusing on the technology when pitching microservices, focus on the flexibility and speed it brings to IT, which have long been the Achilles heel when delivering integrated applications.
Use the accelerators
At a superficial level, it's easy to convey the benefits of microservices. However, as you start to plan a transition to microservices the proposition can seem daunting. Even small organizations have hundreds or thousands of application components that could be made available via a microservice.
Recent Special Features
Thankfully, there are a variety of software platforms that provide an 'integration layer' which essentially serves as a 'translator', integrating with your legacy tools in the technologies they understand and providing a common, standards-based microservice on the other side. Tools like MuleSoft, Boomi, Jitterbit, and others can quickly allow you to start capturing the benefits of microservices without wholesale updates to your existing applications.
This provides a significant additional benefit. If you can create thoughtful microservices, replacing legacy applications simply requires changing some backend 'plumbing' without rebuilding the tools that depend on that microservice.
Identify key IT services that power multiple applications and prioritize them for microservices. A shipping company might start by building order status microservices, just as a retailer might start with inventory services. It may also be tempting to create the 'perfect' microservice for each application, which accommodates every potential scenario and permutation. This approach is a recipe for delayed rollouts and overcomplication. Seek to keep the 'micro' in microservices by making each perform a discrete task. You can always combine multiple services to perform more complex functions, just as you can expand functionality in future versions.
Finally, each service requires a published set of specifications that's maintained on an ongoing basis. A comprehensive library of microservices that are not shared or well-documented accomplishes little. Remember that a key benefit of microservices is that new applications can be built without complex IT projects and approvals, so keeping your services updated and documented is critical for getting the benefit of these services.
There may also be some resistance by owners of the various services that will ultimately be made available via a microservice architecture. With open services, individual teams give up some of their 'gatekeeper' role, which can seem threatening. Ensure that you communicate that their span of control remains intact by preserving the integrity of what happens 'behind' the microservice, and that the broader organization can rapidly benefit from their work rather than having to wait for complex, one-off interfaces.
Read more
Down an invisible road: Service mesh's unpaved path to practicality
Top cloud providers in 2020: AWS, Microsoft Azure, and Google Cloud, hybrid, SaaS players
5 ways technology progressed us in 10 years: The story so far
Python, microservices, and more tech trends for 2020, according to O'Reilly (TechRepublic)