By Stefan Hetges, Founder and Chairman
Are you already using a microservices architecture (MSA)? You probably are, but you don’t even know it!
For example, a Google search generates an average of about 70 microservices when you click the “Google Search” or “I’m Feeling Lucky” buttons. So, it’s no surprise that today about 50% of companies claim to use microservices in one way or another.
In this blog post, I explain the reasons why MSA is of interest and the best way to use it in conjunction with your existing legacy systems. With the right approach and tools, it’s risk free to liberate critical processes from the monolith and deliver them as independently-deployable microservices. An MSA offers many advantages, not only for the development process but also for users and stakeholders.
Microservices Architecture is Not Only a Technology Decision
The decision to use microservices is not just about using new technology. To take full advantage of its benefits, you also have to embrace the development culture of DevOps. You have to consider trade-offs and increased complexity (there is no free lunch). Each microservice is implemented as an independent service, developed by a small team that deploys it independently of all other changes in the system. Smaller autonomous service teams complete their development and make deployment decisions quicker than other organizations.
The good news is that the development culture doesn’t have to change overnight. At the same pace, as you liberate business functionality from a monolithic system, you define the organizational development framework in parallel.
Understand Your Software Assets
Understanding the software assets in a legacy system takes several months or even years using traditional manual approaches. Burdening your organization’s most important resources with the task of understanding the past is wasteful. Intelligent Automation can save you time, boost efficiency and improve quality.
Successful MSA transformation planning of an existing monolith requires understanding of both business processes and their semantics. What are the dependencies to existing business processes? The frequency of calls? The usage of business functions? Where do performance problems lie? What is causing system failures? What are the data sources and interfaces?
Efficiently developing this detailed understanding is an advantage of smartShift’s Intelligent Automation. The use of algorithms and machine learning techniques dramatically reduces this normally time-consuming work.
Selecting Software Assets to Become Microservices
The following seven criteria can help you prioritize which software assets you should liberate from the monolith. If any one of these criteria hold true for a particular software asset, you will likely benefit from running the business functionality in an MSA going forward.
A High Rate of Change
Some of your business processes change frequently. They evolve at different speeds or even in a completely different direction. Our experience shows that about 10%-30% of legacy systems need to be adapted to business requirements very frequently, and the rest to a smaller extent. Relevant processes should be carved out to increase competitiveness and adaptability to market requirements.
Independent Life Cycles
Software changes – and the underlying business process changes – are typically implemented on a fixed-release schedule. Fixed-release schedules mean that innovation isn’t agile, and the chance to gain a competitive market advantage is dampened. Often, innovations either never make the leap into production or don’t get deployed as quickly as needed by the business community. Separating critical services from the core system allows you to iterate quickly and take advantage of new business opportunities. The ability to continuously implement and apply innovations enables you to gain or maintain your leading role in your market, and also to improve upon it.
Independent Scalability
Some business processes have high utilization at certain times (e.g., fiscal-year end) and must be scaled independently from the rest of the application. Seasonality, time dependency, or even demand spikes (e.g., sensors generating high data volumes for processing) are examples of this phenomenon. Autonomous microservices scale independently as the load increases, and the MSA will start multiple service instances. If you leave the modules in the monolithic framework, you have no choice but to scale the entire application, which means that your license and hardware costs must be sized for the worst-case scenario.
Isolating Failure
Your application has an external interface that calls an unreliable service. Your system reacts with a failure, e.g., when some data is not complete or when the uptime of the system does not meet your requirements. You can isolate this dependency from the rest of the system and build a failover mechanism to keep data consistent, or even cache data when the service is unavailable. The microservices architecture mitigates performance degradation due to unreliable third-party dependencies. You don’t have to rely on queuing mechanisms to slow down your system.
Fast Test Cycles
This is the best news of all for companies where long test cycles inhibit innovation. Not only will a small-scale, autonomous microservice be tested much faster, but you’ll also be amazed at how much automation is possible during deployment and testing. The immediate advantage is that unit, integration, and regression tests can be run multiple times per day. Microservices are maintained in distinct repositories, keeping them simple and easing testing. Instead of engaging hordes of business users for testing, you only need a few resources. With a fine-grained MSA approach, problems are isolated and therefore easy to identify, fix and test.
Simplification of Interaction
In a world of highly networked consumers and services, you want the flexibility to exchange one service provider with another or add other providers to ensure you’re never under supplied. With an abstraction layer, you can protect your system from external dependencies that change frequently. A technical layer hides the complexity of the dependency, making migration easier in the future.
Choice of Technology
In a monolith, you have limited options to change the technology stack. The technology stack and the pace of technology adoption is dictated by the supplier/manufacturer. It is even more difficult if your system is old and the original team who built it is long gone.
An MSA structures an application as a collection of loosely coupled services. The project is not a single application, but a set of independently deployable small services, each of which is implemented in its own language. For example, to process a large amount of data, engineers choose Python. Ruby is the right choice for an appealing graphical evaluation, and a large and stable part of the application uses Java. Technology choices also apply to databases. Use elastic search for big data analysis, or divide your enterprise data into highly available data in (for example) SAP HANA and store cold data in Hadoop to save costs while still having it available. You don’t need to choose a technology for an entire project, but instead for a specific task that best fits your needs.
What’s Next?
The MSA candidates have to be liberated from their monolithic legacy confines. smartShift Continuous Intelligent Automation is used to carve out the candidate functionality and to generate the components required to operate the business processes as a service on a new platform. Business functionality is gradually transformed into something better, cheaper, faster, and easier to maintain. In the monolith, the “dead” parts can be retired and removed. If you include new functions during the liberation process, you can make the transformation more attractive for business stakeholders and help to assure their support for your MSA implementation efforts.
Interested in learning more about how you can turn your monolith into microservices? Set up a free consultation with an expert from smartShift today!
DE