Terms cloud-native & microservice architecture have been used interchangeably for years. Microservices have benefits, but also bring challenges, so are they really the go-to solution in all cases? Better understanding & some failed projects led to an evaluation of the suitability of microservices, and resulted in new interest in the various architecture styles in the cloud. We'll look at microservices and monoliths in the context of cloud-native.
3. 3
Cloud-native definition - VMWare
Cloud native is an approach to
building and running applications that
exploits the advantages of the cloud
computing delivery model.1
Cloud native development
incorporates the concepts of
DevOps, continuous delivery,
microservices, and containers. 1
1 https://tanzu.vmware.com/cloud-native
4. 4
Cloud-native definition - Microsoft
Cloud native is about speed and agility. 2
Cloud-native systems embrace microservices, ... 2
2 https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
5. 5
Cloud-native definition – Red Hat
Cloud-native applications are a collection of
small, independent, and loosely coupled
services. 3
You don’t always have to start with
microservices to speed up application
delivery as part of cloud-native apps,
though.3
3 https://www.redhat.com/en/topics/cloud-native-apps
6. 6
Cloud-native definition – CNCF
Cloud native technologies empower organizations to build and run
scalable applications in modern, dynamic environments such as public,
private, and hybrid clouds. Containers, service meshes,
microservices, immutable infrastructure, and declarative APIs
exemplify this approach.
These techniques enable loosely coupled systems that are resilient,
manageable, and observable. Combined with robust automation, they
allow engineers to make high-impact changes frequently and
predictably with minimal toil. 4
4 https://github.com/cncf/toc/blob/master/DEFINITION.md
10. 10
And the survey says…
https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf
https://jakarta.ee/documents/insights/2020-Jakarta-EE-Developer-Survey-Report.pdf https://twitter.com/Jamie_Lee_C/status/1277511259248877568
12. 12
Architecture characteristics
Microservices
Monolith Macroservices Functions
(aaS)
pricing opex
capex
modularity higher
lower
delivery frequency higher
lower
operational complexity higher
lower
fault isolation higher
lower
network demand higher
lower
organization Large number of loose teams
Small number of close teams
Many characteristics are enabled by an architecture but
require organizational capability to deliver
31. 32
Summary
• Cloud-native is essentially about working well in the cloud
o Exploiting the cloud delivery model for faster time to value and
cost optimizations
o Engineered for cloud technologies and delivery
• Microservices are an important tool but aren’t universally applicable
or required for cloud-native
• Understand your application needs, business needs and
organizational capabilities and choose the right technologies and
architecture to suit
32. 33
Useful Resources
• Modernize your valuable Java applications -
https://developer.ibm.com/languages/java/articles/modernize-your-
valuable-java-applications/
• Choose the right Java runtime for the job -
https://developer.ibm.com/languages/java/articles/choose-the-right-
java-runtime-for-the-job/
• Interactive Lab/Tutorial Catalogue -
https://ide.skillsnetwork.site/open-liberty-tutorial-catalogue
People think they have a common understanding of what Cloud native means – a big part of that is microservices. BUT
This year in particular but growing over the years is the ideas that perhaps microservices aren’t the panasea that they were previously believed.
It’s a good time to sit back and think about what this term really means? For some people this means Spring Boot. This can’t be the definition of Cloud-native…. E.g.others can build cloud native Javascript applications no problem.
Not about a technology, it’s about something else….
So, what does it really mean?
As a starting point, quick search online to see what companies that sell software that is cloud-native define it as…
First example is VMWare… they are the company behind VMWare virtualization, and Tanzu Kubernetes platform, and also Cloud Foundry and Spring Boot
They have a long history of being in the cloud native environment, what do they say?
Definition is interesting – don’t refer to it as a thing but rather an approach.
As part of their definition they have graphic (shown on slide)
Includes: - DevOps
Continuous Delivery
Containers
Microservices
It’s the microservices that we’re questioning – is this necessary explicitly linked with cloud native?
Next example is Microsoft definition…large doc that defines cloud native, just picked out a few key points here…
They highlight speed and agility – values you may want to achieve through using cloud but it doesn’t really tell us much about what cloud native really is.
Graphic from their docs
Containers
Backing services – things that you’ll find available in clouds
Automation – devops and continuous delivery aspect of it
Modern deign – so in this case they drill down on 12 factor app
Microservices
Microservices are also included in this graphic, similarly to VMWare, identifying it as a key part of cloud native
Third example is RedHat – interesting because they start out with quite a strong statement of (first statement on slide), whilst it doesn’t state that they have to be microservices, that description does seem to heavily imply this.
Small, independent, loosely coupled – byline of microservices….
Later on in that page you’ll see DevOps, Containers and again Microservices. They pull in APIs as the fourth one, perhaps because they view continuous delivery as a part of DevOps.
All of these companies have a similar vain – it’s about how you develop and how you deploy microservices
Interesting thing about the RedHat definition is that right at the end, there’s this sentence (second quote on slide). Quite important. They’re probably thinking in terms of well some people have applications and they just want to take them off Virtual machines and run them on containers and they want this definition to encompass that. But I think also that it’s the start or the first time of an acknowledgement that microservices weren’t necessarily or 100% the best way to get value out of the cloud.
Having read examples from vendors, decided who better to look for a definition of cloud native than the cloud native computing foundation!
It’s in the name, you would think that they would know what the definition of this term really is.
In their definition, it’s quite interesting, they talk about containers, service meshes and microservices, etc. But they say these exemplify the approach and that what it’s really about is empowering organisations to build and run scalable applications in the cloud.
Whilst microservices are a good way to do this, with containers, it does acknowledge that there are other approaches that fit within this.
What’s interesting from those definitions is that they vary a bit they talk about common technology choices – but a technology choice is not what the definition of cloud native is really about.
They all refer to microservices – leads to a discussion of application architectural styles
Cloud-native is beyond the core architectural style i.e. how you deliver your applications and services).
Start from the right hand, functions as an approach to software delivery is absolutely the most cloud native thing you could probably come up with! I say this because you could deploy functions on premise but mostly people who deploy functions, deploy it in a cloud and they’re paying per usage and how many calls to the function are made. That model doesn’t work if you’re running servers on premise – you don’t get the benefits because you’re paying for the hardware. Functions still run on some sort of hardware somewhere and that needs to be factored in. In the cloud environment they factor that in as a pay-as-you-use model.
If you get coarser grained than that, you get to microservices. May be amusing to refer to microservices as somewhat coarser, but you tend to have more functions than microservices. This is where the industry has been trying to derive the cloud value in this microservice area. Whilst there’s been a lot of notable successes (Spotify, Netflix) where companies have got a lot of value out of microservices, it doesn’t necessarily work best for everyone. There’s a continuity between all of these different styles.
If you read the Gartner reports and they’re hype cycle, microservices and functions are in the trough of disillusionment backed up by stories of organisations who have tried to do microservices examples of failures, lot of concern about whether they’re the right approach. Growing appreciation for different architectural styles.
Some of the early adopters of microservices have been talking about something which combines some of those microservices together to be deployed as a number of larger/coarser grained. These can be described in a number of ways – macroservices seems to be a reasonable way to describe them. Example in this diagram - You have the services being broken three deployable chunks with the set of services within them. Not a monolith. More like a couple of mini-monoliths with well defined APIs around them. Depending on your development org or structure, this can provide a lot of value.
Some people mike refer to this as a modular or cloud native monolith.
Then there’s the true monolith, which doesn’t really exist, where everything is coded within a single application. Very very few have a single monolithic application, they tend ot have a whole series of monolithic applications but the difference is that they don’t have those well defined API boundaries which are present in all of the other architectural styles.
All of these could be built to be cloud native. How is where it gets interesting! Some may be more obvious than others but importantly there is nothing intrinsic about these architectures that means they can’t be done in a way that’s cloud native!
Maybe you’re skeptical about this movement? You don’t have to take my word for it. A short search of the interweb throws up a number of examples and discussions, even from companies such as Uber who have been vocal advocates of Microservice architecture for a number of years.
They’re saying - What you build needs to be appropriate for your organization.
There is a growing interest in applications that are not based on microservices… hence this talk….
Interesting, tweet from someone at Uber shows that they’re moving away from microservices to macroservices – that is because there is a certain scale that needs to be thought about.
Might sound all well and good saying that you have 600 microservices across 1200 containers and I do 50 deploys a day… but we’re not in the industry to compete based on how many containers we have. What we’re here for is to deliver innovation, value and stability to our user base. Microservices work best in some environments but not all.
There’s been some interesting studies done recently that suggest that interest in microservices is actually declining. Not a major decline, just a small decline – this is not the interesting part. What is interesting is the large growth in the monolith area. It’s essentially doubled the number of people responding with an ineptest in the monolith area whereas a few years ago that was an area that people didn’t really want to associate much with.
Not just the Jakarta EE developer survey, but other examples of this renewed interest in monoliths – Jamie’s tweet shows a similar pattern. Strong interest in Monoliths but also a strong interest in Macroservices.
Monoliths went from 12% to 25%
Comparing 2019 to 2020 (links at bottom of graph)
Key reason for this change in interest in microservices. As more and more people try to deploy their application as microservices they fail. Not a bad thing, as failure is how we learn and how we gain nuance – not everyone can spend the amount of money some companies spend on software engineers to build highly efficient, highly effective microservices. But this is what everyone has been attempting to achieve. There’s often many reasons why a microservice project may fail, but there’s one common thread which is the projects which fail have ended up being a distributed monolith.
What this means is you have all the negative traits associated with a distributed applications (method calls and procedure calls are much more efficient than a HTTP network trip – just physics). There are downsides to having lots and lots of microservices that need to be deployed. If you can’t do that independently because perhaps you got your abstractions wrong or your domain wrong, perhaps your organization structure is not set up in a way that doesn’t allow you to set up the microservices independently.
All of the downsides of a monolith and all of the downsides of a microservice, none of the upsides of either.
We talked about there being a number of factors influencing teams to choose different architectural approaches. Here are just a few examples. Note, that the left to right arrows indicate a sliding scale and they’re only ‘tendencies’ not definitive statements. For example, delivery frequency of a Microservice is likely to be higher than a monolith but is not guaranteed. Also, note, that often the benefits of a particular architecture also require investment and organizational capability to deliver them. For example, if you don’t invest in automation technology, your going to struggle to deploy more frequently.
Many different considerations when choosing an architectural style
Understand why certain architectural styles fail
Right hand side more finer grained models
Left hand side more coarser grained models
Starting at the bottom:
Pricing: There are pros and cons to capex and Opex. Functions as a Service is inherently Opex and with the most fine-grained measurement of any model. Monoliths are often Capex, but there are ways to smooth the cost to more of an Opex model.
Delivery frequency/complexity & operational complexity: These both relate the the fact that as we move from left to right, we’re increasing the number of artefacts we create, deploy, manage, debug, and service. There’s cost associated with this, but also benefits
Modularity: One of the big downsides to monoliths is the difficulty in making them modular and preserving that modularity over time. As we move from left to right we further decompose an application into smaller and smaller parts, but also introduce process and network boundaries as a way of enforcing modularity. This increases the chances of creating more loosely coupled, flexible solutions. A word of caution, though, as some have found it very easy to create a distributed monolith – the worst of both worlds.
Network demand & fault isolation: these two come hand-in-hand. With the distribution of more and more components comes the increased use and reliance on the network. Network performance becomes a key gating factor on overall solution performance. Network reliability also affects overall solution availability. Increased isolation helps avoid cascading failures taking down the whole solution but defensive techniques, such as bulkhead, retry and fallback need to be employed to exploit the isolation.
Runtime demands: different architecture patterns favour different runtime characteristics but also different approaches to using the runtime. One the left, we favour runtime stability over a long period of time. We want the runtime to perform well for the longer duration over which the application is deployment. It’s also typical for the server to be something you manage and optimise directly and deploy one or more applications to. On the right-hand side, because the lifetime is shorter and number of request fewer, and the number of instances much higher, the focus is on runtimes being small and fast to start. There is also a shift from server-centric deployment to application-centric, where the server is brought along with the application (e.g. in a lower container image layer). One final point that we’ll explore on the next slide is the correlation between API needs and the architecture patterns. On the left, you typically use a lot of different APIs in a single app whereas on the right, each function or microservice has more modest API needs.
The industry has evolved to essentially a point where there’s a great appreciation for different architectural styles but we saw in the earlier slides that people are really only focusing on microservices when it comes to cloud-native. So where does this leave cloud native?
We’ve seen that cloud-native definitions have a strong association with Microservices.
We’ve seen that microservices are not for everyone, and that applications are being built to a spectrum of architecture styles.
Where does that leave cloud-native?
Let’s take a step back to try to understand cloud-native in more details.
We’ll take a first look at why we even invest in clouds and then go into what it really means to be cloud native, what we’re looking for. Cost.
Clouds are essentially an outsourcing activity – you’ve got someone running a data center, economies of scale – they’re doing it for lots of people, so should hopefully be able to do it cheaper and so be able to pass some of those cost savings on to you as the client. Should be cheaper than using your own datacenter.
Also the dynamics or flexibility of consuming cloud technologies – scale up or down your usage on demand, don’t have to provision enough in youre datacenter for your worst case scenario, instead you can scale for your usage.
Ultimately companies need to make money. They do this by investing proportionally for the opportunity. Cost is a big factor in this. With cloud there are two aspect:
If I run it on cloud infrastructure, I can offset the costs with savings I make on my own datacenter. It’s outsourcing.
If I run it on cloud infrastructure, I can convert some of my large capital expenditures to operational expenditures
Speed is another important factor.
It can be quite long in terms of cycles for getting new things provisioned in a datacenter so you can support a new application, whereas with cloud and cloud native applications, you can provision in the cloud what you need and when you need it. As long as you have the permissions and finance you can provision as and when you need it.
We are in some respects a fashion industry– new technologies and concepts come along
we hear of success stories and sometimes jump on the bandwagon and try to apply concepts without getting a full appreciation of why it worked for company x and why it wouldn’t work for company y – maybe the way they work is different or maybe the demands on their application are different
We need to be careful in investing for the right reasons.
Back to trying extract what the essence of cloud native really is…
Really like this definition from Paul Freemantle – wrote a blogpost over ten years ago, and this phrase was repeated throughout.
It needs to work well in a cloud environment - that’s what we’re trying to achieve!
Blog post had an analogy from one of his team that talked about vehicle and different types of track they can go on (e.g. dirt track vs interstate/motorway/autoban) – point was something that’s been designed for a dirt track isn’t going to be ideal for going down a motorway, and vice versa, if you’ve got a car and you try and take it off road it’s probably not going to be a great experience.
When you want to use a cloud there are certain things you maybe going to do differently – you’re going to way to design, build and deploy your application in way that’s going to work well in a cloud environment
Take the 4 definitions that we started with and see if I could create a workcloud and see what it would show…
Talked a lot about cloud (obviously), cloud-native, development, applications, etc… but that doesn’t really give us an idea of the essence of what cloud native is or the qualities we want to get out of cloud native apps
Show we’re focusing on the wrong ideas. Then tweaked to pull up what’s important.
People are shortcutting to solutions rather than what’s important.
If it uses cloud-native more them that implies it’s self-defining. …
Mention repeatability….
There were some important factors – loosely coupled, observability (deploying something in someone else’s datacenter and potentially deploying any number of these things want to make sure they’re observable for appropriate logging etc), scalable (exploits the cloud delivery model, scaling up and down based on demand), speed (cloud services and cloud technologies are available on tap essentially, gives you the opportunity to speed your delivery profess, but if you’re developing and deploying your applications in a way that doesn’t take advantage of that then you’re not really making the most of the cloud), robust/resilient.
How do we realise those things??
One of the best definitions that we have out there (9/10 years old now), concept of 12 factor applications, also book on going beyond that to 15 factors.
Technology agnostic – talks about key things you need to do in order to work well in the cloud
Created by Heroku – based on real world experienced
Approaches to take to make things loosely coupled – how you deal with backing services and dependencies and how you expose ports etc
Things around how you deploy and scale applications
Characteristics of apps that help them work well in the cloud – treating it as a single service (modern day = container), making them fast to start up and quick to shut down
Characteristics of how you do your delivery - build release run having different stages for those and dev-prod parity, how to make all those environments (dev, QA, testing, etc) as close to prod environment as possible to identify issues as early as possible.
Go through a mapping (like pictures)
Here we have a public cloud, a couple of applications and backing services running in that cloud, we have an arrow which is loosely representing your delivery pipeline, your repositories where you’re going to pull artifacts down from or publish artifacts to…
If we lay 12 factor app over that diagram…
We’ve got the codebase and the pipeline with build release and run and dev/prod parity.
We’ve got the application with it’s process model and concurrency scaling out through processes and the fact that they are disposable.
We’ve got how to handles dependencies, and port binding and backing services and so on…
We’ve got externalizing configuration – configuration that changes between environments, make sure it’s outside of your environment because then you can inject it instead of having to rebuild it at every stage and therefore potentially invalidating earlier testing, you inject it from the outside.
Telemetry – logs being able to understand what’s going on
How to administer – administer through discrete admin tasks
Then look at the 12 factors and go back to the qualities of cloud native that we want that we extracted out of the earlier definitions
Things like Backing services, dependencies and port bindings and config (in some ways) – are all about loose coupling
The process model is about scalability
Logging is about observability
The codebase, build, release, run and Dev/Prod parity is all about being able to rapidly deliver into the cloud
If you do all of these things then you’re going to end up creating cloud-native systems that are robust and resilient.
Interesting to map that down to an instantiation – these are examples of what you could use
For example, your source code might be living in a git repository (might be GitHub, GitLab, Enterprise Git repo, etc)
Triggering builds based on changes, might go through Tekton or Travis or Jenkins, and so on…
Of course there’s also testing to think about, so you’ll have Junit
With the dev/prod parity factor, you’re going to be ideally do some testing in a containerized environment that’s going to closely map what you’re going to be using in production - you could use something like MicroShed testing, for example, which is based on another project called TestContainers
Your repositories, you’re probably going to be using a mirror of Maven central repository for artifacts and publishing to a Docker registry somewhere or pulling things from DockerHub
Then when you get into the cloud environment, commonly you might use Kubernetes, although there are other service types and there may be things you do in terms of the way you design and deploy your application to suit the different application runtime types. Here in this example we’re just using Kubernetes, and we’ve got containers and the application in there.
Lastly for the telemetry or monitoring aspect, you may be using things like elasticsearch, fluent-d, and kibana, so you can have a stack that enables you to create dashboards and have alerts and so on. To help you understand better what’s going on within your application and within the broader system.
So what does this look like for a monolithic application?
Notice the change in title at the top of this slide?
Only thing that changed!
So, here’s an example of a monolithic application.
You might say, well you’re talking to another container but in reality, even monolithic applications talk to other things.
So, the qualities we talked about in terms of 12 factor apps, how to design loosely coupled applications, etc, those apply to monolithic applications, not just microservices.
Let’s have a look at a microservice example….
Again, it looks the same!
So the qualities are the same, essentially it’s just down to how you’ve architecture your applications, which applications they depend on, how they collaborate and so on…
Just to show multiple microservices here…
This shows an example of three applications (maybe they’re macroservices or microservices) but they’re essentially just collaborating applications.
Again, you want to make sure they’re loosely coupled, can cope without each other, they have well designed APIs between them so that you can handle upgrades, etc without breaking the entire system.
We took a look at quite a few definitions of cloud native and their strong association with microservices and the fact that the industry is not just doing microservices.
What this means is that cloud-native isn’t ties to microservices, cloud-native is instead essentially about working well in the cloud.
There are two aspects to this..
One is exploiting cloud from a delivery perspective, so faster time to deliver updates and so on, faster time to get things deployed because the cloud is there ready to go, and also the potential cost optimizations we talked about earlier.
In doing so though, you need to engineer your application for the cloud, so taking into account the technologies that are available in the cloud and also the cloud delivery model, so how you actually go through your pipeline and deploy something into production, scale it up, scale it down and so on…
Microservices are an important tool, I think they are valid for many application types, but they’re not universally applicable and not required for cloud native.
I think it’s probably more right to say that all microservices should be cloud-native but not all cloud native applications should be microservices.
The key is to understand your application needs, understand what your business needs from those applications, and how your organization is set up to be able to deliver those applications. In doing all this you can then choose the right technologies and the right architectural style to suit that particular application.
The characteristic slide showed earlier in this presentation can be a useful tool to help you assess whether your organization is set up for doing microservices for example, or whether you should be doing monolithic or macroservices, etc.
Choose the right modernization approach for your business and application needs
