Category: Consul

Transcript:

Hello! Today I want to spend a little bit of time talking about why microservices?
I think you know we often talk about microservices. It’s definitely a hot buzzword today but I think it’s useful to go one level deeper in terms of why are we actually motivated to adopt a microservices architecture and what are the implications of adopting it right because I think oftentimes we might not be adopting it for the right reasons, or we’re not fully cognizant of all the implications that come with adopting a microservice architecture.

Microservices in High Level:

So maybe starting high level you know what are microservices? Why adopt them?

I think if you look at sort of the way we historically developed applications it had a bit more of a monolithic design pattern, so if we had a large application that had multiple sorts of subsystems, so it might be retail banking and you have you know your login; your balance view; you know transfers; you know bill pay let’s say, as an example, you might have had each of these were built by a different team, so each of this is a distinct application team, but ultimately they’re building pieces sort of a common app, so the challenges in this type of a setting each of the application teams had to coordinate tightly with one another:
team A couldn’t do a release without team B, C and D all being ready. so what you tend to see is a very tight sort of release train, where all the teams have to coordinate on when do you cut the release candidate; when do you do betas; how do you do integration testing you have sort of almost a waterfall development timeline that comes with this.

And the reason is you have this tight coupling of the organization design, you have these four different teams app teams they’re tightly coupled into the application design we’re shipping a single app but it spans multiple parts of the organization.

Scale

Now this is even relatively simpler when you only have 4 teams but for simplicity of drawing you can see how this explodes in complexity, you know as you expand and if you had to say 10 different application teams working on a common code base.
Part of the design of microservices insofar as their technology is it’s closely aligned to the organizational reality, so I think when microservices are best to use the best leverage is when you look at this organizational reality and say “what we really want to do is allow each of these application teams to work independently of one another”, so we still have these different teams but now what we’ve done is actually split them out into different unique services, so each of these is now what we might call a microservice . We took the giant monolith we decomposed it into its constituent parts but we did it in a way that’s ideally aligned to the organization itself, because the goal was what we wanted to eliminate was sort of the human cost of coordination – the cost of each of these app teams having to talk to one another constantly, having to figure out “okay can I cut a release because I have a bug in system A, but code base for B is not ready to go out”? etc.

When microservices are best used?

So this is when I think microservices are best used. When you have this larger organization you have many different teams that need to work together on a common code base, and you can decompose such that each of them now has their own schedule. So if A has has a bug they can deploy without needing to tightly coordinate with B, C and D. Now in reality there’s no free lunch, right? so you know the human cost of coordinating between these teams on a release that has to go somewhere. There still is a coordination cost – we’re just moving it around. This is okay we’re making trade-offs here so the trade-off now becomes the great if a wants to be able to deploy at any time because they’re fixing a bug or they’re adding new features. Well if they have dependencies – if B and C depend on A then they have to have an API contract. They can’t just change their API because they’re pushing out a bug fix because they’re going to break B and C.
So part of this now requires that you have a little bit more discipline a little bit more rigor in terms of how do you do things like API management. You have to
actually manage versioning; you have to have some sort of a deprecation schedule or work at least closely with your downstream to coordinate what might be a breaking change.
So in general when you’re in a mode of “I’m just fixing a bug – I’m not changing my API” that’s great. You don’t have to coordinate – you have total freedom. If I’m adding net new APIs that’s great – I don’t have to tightly coordinate.

New challenges

As you break things that’s when you still need to have some of that coordination or you need to have you know a well-known policy of how you do it: you add new features you have a deprecation period B and C can update independently and you know move to the newer API as an example.
Now at the same time you also inherit a set of operational challenges when you go to microservices.
Here by virtue of deploying this as a single monolithic application, if A needed to interact with D – this is an in memory function call. We don’t have to worry about networks. We don’t have to worry about authentication or authorization or all the challenges that come with now becoming a distributed system, so I think as you move into this world you inherit a bunch of challenges. Part of them around things like “how did these pieces discover and network to one another” so if A needs to communicate to D “how do we do that discovery?”

Networking challenges

So there’s a whole set of service networking challenges that we need to look at
so when you talk about service networking. The most basic initial challenge is how do you just do Discovery?
so A needs to find D somehow to be able to route to it – this is piece one.
I think especially as we move to a more sort of secure posture we don’t want any app to be able to call any app you have to start to think about things like “how do I authenticate and authorize these different interactions”
so A might be allowed to talk to D but C should not be allowed to. so I need to have some way to authenticate to note is my caller A as my caller B as my caller C that’s the off end challenge.

Security challenges

Then I have an authorization challenge where I define and say “which of these sort of communications are allowed or disallowed?”.
Then as you get more sophisticated you have things like a traffic management challenge right so we talk about traffic management you might get into scenarios where you’re saying “great I’m actually running obviously multiple copies of service A. Maybe I want to send 90% of my traffic to version 1 and 10% to version 2 so I can do a canary or a blue green test before going 100 rolled out to version 2.
As you get more sophisticated, these become your sort of networking challenges that you didn’t necessarily have or at least not to the same degree when you had kind of a monolithic challenge. I think at the same time closely related to some of these pieces for example (authentication and authorization)
is things like secret management credential management if the way I’m authenticating A talking to D is I’m using a signed JWT token or I’m using a certificate that’s signed to prove my identity, well then I have a challenge of how do these applications get those certificates get those JWTs sign and verify transactions
So that’s where you typically have sort of a secret management problem as well, and so this might be something where you’re using a solution like Vault.

This might be something we’re using a solution like Consul that’s providing the networking and then like I said Vault might be providing this, but I think part of the way to think about it again coming back to this organizational challenge is the reason and the motivator to go to this kind of microservice architecture is ultimately i want to make these application teams more agile. So what I don’t want to do is burden them with all of this complexity of service networking and secret management and application deployment etc
because in some sense that’s going to take away from the original goal which is to let them focus on the application
and allow them to be more agile so I think often when you’re moving to a microservices design what’s helpful to think about is what’s the platform experience right and so what we really want ideally is that our developers are really focused on you know their source code; their application and then you know to the lightest degree possible
some additional metadata you know this might live in a manifest of sorts, right?
That describes you know what their application needs what regions it should run in upstream dependencies; configuration … things like that, and then these should really be the inputs to sort of a platform layer.

The Platform Layer

The platform layer is ultimately what should shield them from the reality of how this thing operates.
Everything below this line really becomes an operational concern.

So this is where you really see teams that are successful with this you have sort of a strong notion of a platform team a central operations team that they own everything up to this line, and the developers can really focus on what matters to them — the actual app ; the lifecycle and operation of that and to the degree possible we can mask these things right The platform teams obviously then have to deal with a bunch of these pieces of you know how do we standardize things on you know infrastructure management;  provisioning how do we think about security and you know things like secret management how do we do networking you know what how’s our application runtime actually look like you know what’s our container runtime platform as an example;
you know how do we do builds; how do we do observability.