At the end of each of our webinars, we hold a Q&A session where the audience can ask questions that arose from the webinar content. This blog series highlights some of those questions to expose them to a wider audience.
This week the questions come from the webinar, New Priorities for Managing Hybrid Cloud, Containers, and DevOps, where Enterprise Management Associates’ (EMA) Torsten Volk, Managing Research Director - Hybrid Cloud, SDDC & Machine Learning, and Embotics EVP of Engineering & Chief Technology Officer, Scott H. Davis discussed how to enable your digital business to move faster with provisioning automation and DevOps, while at the same time reducing costs and maintaining proper governance.
Q1: Why do you think microservices will be successful when service oriented architecture (SOA) has failed?
Scott: SOA was a great idea, but it was ahead of its time. The hardware wasn't powerful enough, the right standards and technologies weren't available at the time. So it was great in theory but with SOA, the applications weren't carved up into fine grained enough pieces and in order to get adequate performance they would run in a shared address space, so there were all kinds of ad-hoc interactions.
Today the hardware is fast enough for true microservices, where you separate out each individual component into a separate building block, each microservice does one and only one function, there's no shared data between the pieces and they're basically immutable.
This environment enables separate development teams and separate deployment schedules for each individual microservice. This enables you to give a rich scale out environment for the applications. The time's really right for microservices now where SOA was just too early.
Torsten: It is turnkey, you can just go and try this out on Lambda, or Microsoft, or Google, without having to make big plans.You can do a very simple test for almost no money, and do it online. It's the same with containers, you can't just, without much risk, prototype it and try it out, and if you like it create something, if not, you've learned something. That's not the same with SOA, that was not as simple.
Q2: Is it possible to gradually transition traditional monolithic internal applications to a microservice architecture new functionality is built out, or is investment in a major rewrite needed to get there?
Scott: The answer is, yes, you can do things gradually and iteratively. The technique that I'm in favor of here is where you take a monolithic application and the first thing you invest in is an API gateway. This is a thin shim layer that sits in front of your monolithic application and exposes the functions that you're going to call. Once that is in place, you can now write new functionality as its own separate microservice while all the rest of the APIs in the gateway are still calling the monolithic app. This enables you to gradually start deploying new functions as microservices, and as your schedule and resource commitments permit, you can pull functions out of the monolithic application, and make them their own microservice.
This technique is not all or nothing, you gradually replace functionality over time and eventually you get to where the monolith has nothing left in it and you're entirely microservices or you can stop somewhere in between.
Q3: Is public cloud always the least expensive option, and where might private clouds be more cost effective?
Torsten: The clear answer there is a no, public cloud is not always the most cost effective option. You have to look at your workload characteristics, for example, if you have the capability to turn off a specifically CPU intensive workload most of the time, only run it three days out of seven, then as a public cloud workload, it would probably still be reasonably cost efficient. But you have a lot more flexibility if you pull that kind of a workload in your own data center and stack it together with the other workload.
It's like a game of Tetris, it's a it's a puzzle to know your workloads, to see how hard they are on the network, on the CPU, what the dependencies are with other apps, what the risk is to to get it back out again in terms of cost, how much the service provider is charging you, and how much does it cost to to move it to the cloud in the first place from a band cost perspective.
The cost may be prohibitive even though it looked like the public cloud was the cheapest. The devil really lies in the details, and every individual custom environment needs to be evaluated.
Scott: The answer is always it depends. There's a lot of variables to consider. Typically a good rule of thumb is that fast, transient, temporary workloads are almost always best done in the public cloud. Long-lived steady state workloads without big spikes are more cost effective to be on-prem. It also very much depends on the governance of the data. Don't approach it from the attitude that public cloud is always cheaper, look at the details.
You can watch the complete webinar with Torsten and Scott by clicking the link below.