Microservices and cloud-native development versus traditional development
Kyle Brown, Distinguished Engineer at IBM, shares his experience assisting IBM Cloud Garage clients with the adoption of microservices leveraging the tools and practices defined in the Garage Method.
What are some of the biggest barriers or challenges you see enterprises face for traditional application development?
We’ve had a very good run for the last 20 years or so with distributed systems development in the enterprise, but time has started to show some of the downsides of traditional development styles. First of all, distributed systems have grown enormous – it’s very common to see corporate websites for retailing or customer service with hundreds or thousands of discrete functions. Likewise, I’ve seen many Java EAR files at those customers whose size are measured in gigabytes. So when you have a site that large, and one that may have been originally built 15 or more years ago, there are going to be parts of it that need to be updated to today’s business realities. The second business challenge is that the pace of business change is much more rapid now than it was in the 90s and 2000s. Now that the cell phone replacement cycle is down to a year or less, and customers are constantly updating their apps on those phones—the idea that a corporate website can remain static for months at a time is simply not in touch with the times.
These two trends combined together create a challenge for traditional top-down enterprise development styles. It requires an approach that is both more customer-centric and able to react more quickly, and it also requires an architecture that is able to adapt to and facilitate these rapid changes.
Also, in the past, when development cycles were longer, waterfall-based methods were appropriate, or at least not as much of a hindrance as they are now. If you have the luxury of time, then the downsides of top-down approaches are less apparent. As a side effect, that led to the predominance of outsourcing since if you were going to define everything up front anyway, then you might as well perform the programming work where the labor was cheapest. All of those trends are now being called into question.
What do you see that suggests that of microservices and cloud-native development can change this situation or help address these barriers?
Let’s start with a definition of what microservices are. The microservices approach is a way of decomposing an application into modules with well-defined interfaces that each performs one and only one business function. These modules (or microservices) are independently deployed and operated by a small team who owns the entire lifecycle of the service. The reason this is important is that this goes back to a very old principle in computer science that was discovered by Fred Brooks – that adding people to a late project only makes it later by increasing the number of communication paths within the team.
“When you write an application following the microservices architecture, it is automatically cloud-native.
Instead, microservices accelerate delivery by minimizing communication and coordination between people while reducing the scope and risk of change. Why is this important? Because in order to meet the rapidly changing pace of development we have to be able to limit both the scope of what we are doing and increase the speed at which applications can be developed. Microservices help with that. Another critically important factor that you can’t ignore is the importance of the cloud for deployment. The cloud is rapidly becoming the de-facto standard for deployment of new and modified applications. That has led to the rise of “cloud-native” application development approaches that take advantage of all of the facilities provided by the cloud-like elastic scaling, immutable deployments and disposable instances. When you write an application following the microservices architecture, it is automatically cloud-native. That is another factor that is accelerating the adoption of the architectural approach.
Now, as great as microservices are, there are some downsides, or at least someplace where they’re not always appropriate. We’ve found that while the microservice approach is perfect for what we at IBM call Systems of Interaction, that it may not be the best approach for Systems of Record, especially those that already exist and change slowly and where there may be no maintenance gains from refactoring or rewriting those systems into microservices.
What does IBM’s provide to help enterprises transform their systems to a micro service and cloud-native approach?
We bring several things to the table that help our customers to adopt the cloud-native and the microservices approach. First and foremost is our open-standards based cloud platform, IBM Cloud. You can’t underestimate the importance of open standards when choosing a cloud platform, and IBM’s embrace of standards such as Cloud Foundry, Docker and Kubernetes makes it possible for you to develop not only our cloud, but for on-premise private clouds and other vendor’s clouds as well, giving you unprecedented portability.
“The Garage is our secret weapon in helping customers rapidly move to the cloud and microservices…
Second, we have the comprehensive IBM Cloud Garage Method. You can only be successful with cloud-native and microservices architectures if you build them within a methodological framework that includes the kind of practices such as small, autonomous, co-located teams, test-driven development and continuous integration and continuous delivery that make the approach viable. Finally, we have our people, particularly in the IBM Cloud Garage. The Garage is our secret weapon in helping customers rapidly move to the cloud and microservices by showing them how to apply the method to build systems on Bluemix using all of the latest technologies, practices and approaches. You gain experience with those approaches and technologies at the very same time that you’re building a minimum viable product – the first step toward adopting the approach on all of your systems.
There are still many enterprises that have concerns about cloud migration from either a security or performance point of view. How do you address these concerns?
I’ve heard these concerns many times and it comes down to the fact that neither security nor performance should be a driving factor. It’s possible to build systems on the cloud that are more secure and more performant than current on-premise systems! The key is that you don’t build them in the same way as you do on-premise systems, and it’s that change that is actually what is difficult for teams to understand. For instance, with security, you have to implement security at every layer; you can’t be satisfied with only securing the front-end of your applications thinking that anything behind your firewall is safe by default. The extra attention makes the overall system much more secure. Likewise with performance, in the cloud you have to build systems that are horizontally scalable – that means you have to develop algorithms that work with horizontally scalable systems – which end up not only being better able to scale and thus perform, but makes them more resilient as well.
What advice can you give to enterprises who are outsourcing and waterfall-oriented and want to adopt agile processes and cloud-native development?
The important thing is that you have to begin by changing your mindset. In many countries we’re starting to see a backlash against outsourcing as firms realize that software assets are an important category of intellectual property— a firm should be responsible for maintaining and creating on their own just as they create intellectual capital of other types as part of their core competency.
Software is everywhere now – the IoT and the Cloud now pervade every part of our lives, and any firm that thinks that writing software is outside of what they should be doing will find themselves quickly replaced in the market by more innovative firms that realize that the software is the critical factor – witness the demise of traditional taxicabs in the face of Uber and Lyft.
Once that first shift is made, then the second shift comes more easily. If you realize that building software is critical to your productivity and growth, then you want to build it as quickly as possible and to be able to try new things without having to wait months for a result. That leads directly to the Agile approach and away from a waterfall-based mindset that views software projects as large, multi-year capital expenditures. If you want to fully embrace Agile methods, then you need a technology base that facilitates that, and cloud-native approaches and microservices architectures give you that platform.