Michelle Coppens :: Webinar Producer
Hello everyone and welcome to today's webinar titled designing and implementing micro services. Our speaker today is Michael Forrester.
Michael is a 20 YEAR, IT industry veteran and an Amazon authorized instructor, whose passion is to train lead and create technology expertise so that technology teams can deliver software, better, faster smarter.
And with visibility and transparency, back to the business.
Whether it's rolling out a whole new technology for Team delivery training the Uber nerds on cloud container and micro services.
Or coaching others on how to effectively inspire the technical team and engineers in your organization Michaels focus is to elevate and inform one person at a time.
Gotta love that. Now before we get started with a webinar. I want to talk about the functionalities during the session. Everyone's microphones will be muted. So if you have any questions.
Please enter them in that Q AMP a box at the bottom of your screen. We're going to have a dedicated question answer session at the end of the session, but don't hesitate to post those questions whenever they come up
Today's webinar is being recorded and will send a copy to everyone who registered by the end of the week. Alright, let's get started. You can take it away. Michael
All right, thank you for them. Sure. Appreciate that.
Alright so introductions already been given. I'm Michael for sir I'll be your primary guide and facilitator today for our exploration of designing and implementing microservices.
So what we're going to focus on. We're talking about what we're going to talk about and then I'll read kind of rehash it at the end, again, is that we're going to talk about how do we get to the design of microservices some definitions, some principles to consider.
And then how do we go from design, implementation, some kind of implementation processes. Some evolutions there.
And then when we're implementing microservices themselves. What do we want to think about what are the best practices. What are some things to consider. Also, when we're actually doing our implementation so
What are microservices. What is the official version. Well, most people refer to Eric Evans has books about Domain Driven Design.
But microservices have been around for quite some time, at least the concept, but there's been this driver, especially over the last six to seven years where microservices have gained momentum.
For a variety of different reasons. But a good starting places James Lewis has kind of foundational article microservices, where he described microservices.
Has an approach to developing a single application has a suite of services, not just a single process, but a suite of services and each of these services.
Is running in its own process and communicating with lightweight mechanisms and and nowadays that would be API's restful services. Right. And these individual services that make up this application.
Suite or product they each have are centered around single business capabilities such as like billing or profiling or presentation layer.
And they're independently deployable by fully automated deployment machinery.
So the idea here is that this is is that we're taking what was previously all of the business concerns and we are separating it out into single independently deployable scalable and manageable.
Services and these services, by the way, just as a little preview are supported and managed by teams who are super focused on that services business domain. That's the official version so pictures always worth 1000 words so
Here on the left, we have a monolith and monolith, by the way, means month one stone. So sometimes I refer to them as macro services.
And in that context, what we're talking about is, we're talking about a single reasonable process usually on a single server.
That contains a bunch of business concerns and on the right we have a bunch of microservices.
And there are a bunch of independent processes they might also be running co located on the same server, especially if you're using containers.
And each of those governance one subsection of the business concerns. So talking about the left for just a second. First
The monolithic application is going to take like profiling and billing and presentation and a bunch of the business concerns. Let's say inventories in there as well. And those are represented by all of the odd colors, shapes there inside on the left on those little white boxes.
And as you can see the orange. The red the burgundy. The blue. The green
Those are all business concerns and they're all talking to each other through it. Basically, in our process and our memory. Right. And it's all just contained right in one memory space.
And when you need to deploy more orange, because let's say all the sudden your billing is getting really heavily hit or heavily consumed.
You actually have to scale the whole thing because they're all tightly coupled. There's no independence around scalability deploy ability and therefore performance.
On the right hand side we have micro services and what you've done is you've taken each of these were previously kind of just
Contexts in memory in a single application or even libraries or frameworks and you've made them independent and as you can see, for example,
The orange shapes. There's five of those. And there's only three of the green shapes, because in this particular drawing
You didn't need as many of that particular business concern, let's say it was Billing versus profile versus inventory versus like streaming, you know, if we were doing. Like, for example, Netflix.
And so what happens is if you need more green. For example, let's say that was streaming, you would just independently add more of the green processes and or containers or whatever unit of deployment, you were using
You would just add more of those. And there will be one team and one data store that that team would manage that would serve those green processes.
And so it isolates kind of the evolution because what happens is that previously were developing one process that would handle all of our business concerns and over on the right, we've
Fraction aided that single application into several smaller services, each of which focuses on the one and only one business concern.
So what is the, the more complex answer because Michael you like we talked about a lot of stuff here. Right.
So the first is just really the separate the the component ization or, you know, creating division of services. How do we separate things into individual business concerns and at what level of granularity. Do we do that.
If we do billing for example let's say billing is one of our first micro services because we're going to slice pieces off of our monolith, and we're going to do a migration. Let's say we're going to tackle billing
Is billing so big that we might need a billing sub service right for credit cards versus, you know, PayPal or G pay or some other service or can that all be contained and managed by one team.
So the first start when you do microservices, is that you are basically taking these business Christian's business services and you're slicing them up. You're taking these concerns and you're slicing them up.
They are organized around business capabilities, meaning again. What are the business terms. For example, if you were Netflix, you might have streaming
You might have personalized recommendations, you might have trending items you might have. What did we just buy and all of those would be services that we provide information and feedback back to the user.
Now the idea here is that these are products not projects and the mindset, there is that when you go to a micro services model.
You are, in a sense, turning through traditional hey I've developed it, and now I'm going to hand it to a maintenance team you're turning that on its side.
You're basically saying if you build it, you're going to run it, which means that you now own a product from conception
All the way to maintenance and delivery and you're going to own that whole lifecycle. Has it integrates
And so you're not doing a project where you just develop some software and they give it to a maintenance team or an operations team. You are now a product owner and you're now part of a cross functional team that will own this micro service for its entire lifecycle.
Part of this also when we go to microservices, is that we want the network. We want to assume that the network is simple. Some people call that a dumb pipe, but it's a simple pipe.
Meaning, we're not passing it to a service bus that's going to do ATL or any kind of data transformation. Right. We are taking care of all of that in house and we are offering
To publish what we can do through these smart endpoints are standard interfaces. Also, we call them now API's RESTful APIs.
And that could change over time. Maybe there's a new technology in 10 years but that's what we're doing now and have been doing for quite some time.
As that we're publishing ReSTful interfaces these smart endpoints and they act as an abstraction layer to connect with all the classes and other items on the back end.
Part of this also when you run microservices teams.
Is that you are moving to a more decentralized can of governance model where you're saying these teams can run whatever technology for database whatever technology frameworks and libraries, they need
They can even use whatever deployment model they made as long as they meet the business concerns. Now, does that mean everything becomes decentralize no
Human might still need need single sign on, and that might be a cross cutting concern.
You might still needs centralized logging. So all of these micro services might need to talk to a centralized logging service. All of these micro services might need to talk to a centralized authorization authentication and Identity Service.
But for the most part, you are disseminating and delegating power down to these micro services and subsequently to the teams that manage them.
So the idea here is to empower these teams. And in the end, the cost of that empowerment is they take full responsibility for production running usage visibility telemetry reliability everything
As a result of that, there's also decentralized data management because, for example, the profile.
You know, micro service might need its own profile database that's very different from the billing database and they're going to be different from a security concern standpoint as well.
And if the billing team needs to talk over to the profile team, they're going to do it through RESTful APIs. No other service will have direct access to another services database.
Meaning that the billing team is not going to talk directly to the profile database, they have to go through an API.
Because that database is a dependency for that team and no one else gets access except for the servicing question.
So you're going to take that previous big database that handled all of the monolith concerns and you're going to take data out and fraction eight and out for the microservices question.
There are obvious costs in terms of complexity and some replication and caching for that. But for the most part, data goes to where the service lives.
The other part of that is that because these are microservices, and now you're taking what was previously a monolith that handled a lot of business concerns and you're breaking it out into smaller services.
You have to become really good at infrastructure automation.
Because you took something that probably has 10 2030 microservices now and you're now replicating and across a larger infrastructure and you've got all these tiny little components that are sitting there and when one of them fails.
Your service can be down. And so you've got to get really good at deployment. You got to get really good at self healing and troubleshooting get really good at automated testing all these pieces.
For interoperability, not just at a macro level with the product, but also individually with the micro service itself. So you've got to become really strong at infrastructure automation, but that's a key part of like microservices. If you're doing microservices. This is a component of it.
Also, when you do microservices, you want to design for failure assume that you're not going to have access to your own database or someone else's API or some, what do you do
Grace will fail over. Here's a good example of that. When you go to Netflix this page and you load up your own personal homepage.
There's a series of like here. Here's what's trending continue watching this. Here's what's recommended for you. Here's our top 10 in the United States. And when one of those micro services fails, you don't even know.
All of a sudden your personalized recommendations are off the page, but you don't know because instead they just tell you, hey, this is what we've bought lately. Do you want to watch the latest version of the flash
And you might be going well. That's kind of personalized recommendation. I'm not even interested in the flash
But you didn't even know that that microservice failed, all you saw was a change in your presentation layer because it fail gracefully and just replace it with something else that might be less relevant
But still shows Netflix content. So you want to design for those kind of failures anticipate failure in design for it.
And then, of course, evolutionary design, which is also known as, in a sense, as iterative design.
You want to evolve services. So because you are running a product and not to project and you own it has, it runs through this life cycle of concepts and features to delivery and concepts and features to delivery.
You're going to evolve these services because typically you're going to start with a monolith with your startup or business model or even new idea, and you're going to evolve to microservices.
So evolution is a huge part of microservice design because that's why we're doing it so we can get to smaller batch sizes with one team that does one thing it doesn't exceptionally well for the business.
So that was, that was the more complex answer.
So the simple answer because you know like to end with something that's a little more digestible right then all that complexity. I just kind of threw at you, which is that they are composed of services or many applications that are available on a network.
Through a machine interface. For example, an API.
The size of these services is important because it's going to be one or a subset of one business concern. That's what microservices are
And, you know, there are you know system level optimization goals, you know, improving changeability improving speed to market that there are a bunch of outcomes of this that are all natural byproducts of moving to a smaller
More focused application, right, and that's the simplest answer for what microservices represent
Now, somewhere in there. How small is small for a micro service. Well, as long as you're meeting one business context and it's independently scalable deployable you're they're managed by one team.
So I will tell you this is that most of our architecture decisions, just as an additional corollary to why we would do microservices, is that we are people are a hot and excited about microservices now.
Because it reduces coordination costs. I heard, I think, was Ward Cunningham and he said technical debt is that feeling you get when you go to make a change to an application, you know that sinking feeling or someone comes to you and says, Hey, you know, we need to change the
Billing module and you're like, oh man, the billing module. Got it. So got so many dependencies and so brittle and it doesn't have any tests. You know that feeling you get when you go to make a change the code.
That usually means that you have technical debt. And that's the natural evolution of what happens with a monolith, particularly when you don't
Continually refactor or improve a monolith microservices can still suffer from that problem.
But when you're using microservices your greatly reducing coordination costs because you don't have to coordinate with another team.
As long as you publish an API, a RESTful interface that contract and you don't change that contract, you don't change. No, but you can add to the interface, but you can't change the contract.
As long as you're doing that, then you don't necessarily need to coordinate with another team.
If you're serving through your interface pizza hot dogs and tacos and you decide that you want to add sushi. You can add sushi. But as long as you don't take away pizza hot dog and tacos through your interface.
No one's gonna complain because the way that they've interfaced with your system is still standardized and if you want to add sushi into that no one's gonna care right
Except for the people who wants to she who have probably asked you for hopefully. Hopefully the business that would be the idea
So it's about minimizing coordination costs so that you can take a team that can go and iterate fast without breaking any contracts with anybody who might be using our services.
That, by the way you has to be done in a secure manner. Obviously safety in terms of reliability and test stability is there, and it must be simple.
You're making things super complex that typically won't work. But it's about keeping that locality and that simplicity in the team that's making the decisions.
So the other part of that is that why would we choose microservices, because it allows for technological heterogeneity. It allows us basically to
Not have to like coordinate Java calls with Java like in constraints if everything's an API. And it's published and it's well known and it's well formed and it's easily consumable
Then the underlying classes, some classes frameworks libraries or whatever back end technology we're using doesn't matter. I don't need to know that you're using Mongo DB on the back end versus Cassandra. That's not important to me.
If I try to retrieve data off your API. Can I get it. That's what I'm interested in. And I'm not tied into what technology you're using
And so technological heterogeneity where it's basically allows you to mix and match technologies has the team sees fit that microservices team sees fit. That's another why from microservices, because it allows for evolution.
And of course, you don't have to coordinate deployments anymore. You imagine with a model, if you have to have like six or seven modules all tested and integrated and regression test and and working together.
With microservices. Again, if you're publishing through a consumable standard interface like in a RESTful API.
Then you can deploy independently as long as you're not doing any breaking changes you can, by the way, do breaking changes with your contract. Just know that you want to give people lead times to change how they're interacting with your API. If you decide to go that route.
That's another why from microservices, is that partition scalability and independence of deployment.
Another piece to this is that you might have a bunch of teams working in modules on your monolith, and because they can't deploy independently and they can't
They can't go fast. And apparently, you might have one team that has a different level of velocity than another team just because of the complexity of the business concern, they're handling.
And if you can separate that off and make it independently deployable and scalable. That also means you can take that team and isolate them as well.
So that that you know let's say Amazon's to pizza team can go as fast as they want as long as they don't make any breaking changes.
And so then that allows all these teams to, in a sense, decouple their schedules and allows them to form in a way that that allows their mindsets and their local ideologies to take root in their team.
And so it reduced the cost of coordination which is really what we're looking for.
We want teams that want to go fast, that can go faster. Go faster there so they can iterate through features and ideas.
In teams that need more stability and slows because of the complexity of what they're dealing with, they can go slower.
And both teams can operate an independent schedules without dependencies, forcing everybody to the lowest common denominator speed. That's what we've seen with monoliths is that you will always deploy at the rate of your slowest team microservices breaks that
The other piece of course is that because of the dependencies and remove there's no more unnecessary. You don't have to coordinate life cycles anymore. I need feature a in this module for I can release FEATURE BE
That might still be true, there might still be some dependencies, but for the most part, you can just deploy independently and implement features and then you can toggle them on when TMA has theirs on right
And so dependencies also get less tightly coupled because you can just roll them out. When you're ready, and you can move on to the next feature product owners love that.
Again, this allows you to go faster. But you still are you the cost of you taking that going faster and time to market with smaller batch sizes smaller concerns, but far more responsibility for security, stability, all of the operational concerns.
So yay all your problems are solved. You've got to make sure if this right. Unfortunately, nothing's a panacea. If that was the case. Well, we would have all dropped what we were doing and already moved over right so
So here's some other design considerations to think about. Now that we've talked a little bit about the what and the why of microservices.
First. And this, by the way, is always true in technology.
People are the biggest challenge and they are also the solution. So when you design. You want to keep people in mind because they're either going to help you or hinder you depending on what you do.
And you want to make sure that your designs. When you go to microservices that you keep people first. And here's a few questions to think about
One when you design, but let's say you're going from modeling for micro service and you're designing your first microservice who is going to be writing maintaining testing and supporting your microservice
Do they do they have the skills are they on board. Are they interested in it, do they buy into the story, or do they at least disagree and commit
Who is going to be doing the operational ization who's going to be doing the testing, who's going to be doing the patching. Don't worry, it's gonna be somebody on your team, but do you know who that is. And do they have the skills to support what you're trying to achieve.
To how will people outside of the core team access to service hopefully today. Your answer is an API.
If you're offering something that's a little more tightly coupled I'd recommend that you look at that.
But how you're going to publish that API, you're going to have documentation endpoints isn't going to be remarkably independent, like, What would, what are you going to do to make that work for people
What technologies are going to use. You can use MongoDB Cassandra orient DB right I can use the cloud service you're going to use RDS you can use dynamo going to use
Document DB was was really just Mongo right you're using it for a graph database you're looking for any OJ.
What core technology. What frameworks, you can use going to write it and go, because you really want, you know, a G RPC to give you lightning fast backend services or maybe you're gonna go node, because you've got, you know, React and Angular, you need all kinds of stuff for the front end.
Is what we are doing when you're designing Microsoft is going to meet the goals for the customers or the business.
So if you're publishing an API. How is that information going to get to the customers. What if a customer is like Netflix. Oh, you need the presentation.
micro service to accept and be able to talk to your API's because you've got you've got the recommender and you're going to publish those recommendations out
Through the presenter which Netflix uses to present their web page. Oh.
Yeah, you probably want to get comfortable talking to their API and understand how they're going to consume and what data format. So looking for. I want to make sure that's working as well.
And then what are the coronation costs if, for example, you're the billing team and you're going to retain
All of the for example the user IDs, which is a unique number that identifies users in times your entire organization.
What are you going to do when every other service hits your service to get the user ID, because they need to know what it is for security or for
You know, credit card or for profile or for recommender. Are you going to offer. Maybe there's a separate service for that.
Maybe you're going to offer it. You're going to beef up your services to handle it. So remember there are coordination and dependency costs if you're involved in any of those chains. How are you going to handle that. Right. And who's going to do it.
The other piece is how do we right sized services, you know, the questions here, are you handling one and only one business contacts or you're doing a subset of a business context.
Is your process independently deployable and scalable that there's a little cut off there. I'm sure that was me, is our process independently deployable are scalable. That's what it says is it service right sized and does it handle one business concern.
The other is we want to build services, only we want to build services that do one thing and one thing. Well, and when we do that, we are shifting complexity.
Like you hear this battle cry for example for Cooper daddy's and I mean my Cooper daddy's specialist. So I love Cooper daddy's I think it's great.
But Cooper Nettie shifts, what was previously an application developers responsibility around
You know encryption and circuit breaking and all of these other kind of mandates and it moves it more towards the DevOps slash operational side.
Remember these problems still have to be solved. Who's solving them. If you're not solving them somebody else's
So when you go to design your microservices, and you're solving problems. Make sure you know that if you will just get rid of that whole piece of complexity.
Who's going to solve it. Who's going to do circuit breaking. Now who's going to do end to end encryption.
Who's going to do backups, who's going to maintain five nines. If you're not handling the presentation layer. Is there a team that's now doing the presentation layer. How are they handling that
You want to be prepared. Because, like, who's going to do that offloading. What's the cost. Typically, the cost of giving responsibility for complexity to somebody else is control.
That's fine. For example, developers. If you decide to use, like for example service mesh with Cooper 90s.
Circuit breaking is now long longer going to sit. Tt at time to lives are no longer going to sit with the application developer
That patterns going to actually go with operations, but you know now that you guys are all on the same team. You guys can control that. But that means that someone or a team of people
In your little micro services team is going to handle that is you know is that person ready to do that. Do you have the technology do you have answers for those questions.
And you really want to focus on your core business domain if you're doing credit card processing don't get into profile management. That's not what your microservices about
And if you want to manage multiple microservices with a single team that actually is totally fine.
Just make sure that you don't exceed a certain number of microservices, I would say, in my experience, no more than three and the micro services all have to be related to a single business domain, for example, recommend. Ideally though one micro service one team. That's it.
You do I want to, I think, look at cloud native architectures. And by the way, I'm not distinguishing between public and private cloud. I'm not throwing that out there.
But do note that I am there are some references here this early public cloud, because
The one of the battle cries out here for large enterprise companies that have, you know, hundred thousand plus users, whatnot is, well, we don't want to get vendor lock in.
Well, just be aware that every design decision you make offers some kind of technological lock in. It's fine if you choose Java or node or go or rest or whatever.
But guess what you are, in a sense, there's going to be a migration cost to get out of that technology right
So clouds no different if you know, but there are choices, some choices are better. So I'll like I'll pick on AWS for a second because I have an Amazon authorized instructor and so I pick on them all the time.
Is that okay, so you're like, Well, you know, we really want a great data store.
But I think we're going to use RDS which is the relational database service if you use Amazon's relational database service, by the way.
It's offering standard technologies. It's Oracle SQL Maria DB Postgres or my SQL.
Guess what, if you rip that database out and run my SQL on another system and you move your application over there. It's going to behave exactly the same way it did on RDS because RDS is just a relational database service.
Offering open source databases. But let's say instead you're like,
Amazon told us about Aurora, which is a cloud native database that mimics Postgres in my SQL and it's like six through three to five times to performance, depending on which flavor that you're using.
We're going to use that. Well guess what, you can't rip that out of AWS. So that's a different technological decision.
Or let's say you use dynamo DB, which is their own no SQL service that's that's an investment decision. Is that a problem as far as I know.
AWS is a great partner but if your business is saying to you, you know what, AWS has started to compete with us.
From a ad tech perspective. And so we need to make sure that we're more abstract and flexible, then yes, by all means, be flexible. Just know though.
That managed services are out there in the cloud and of architecture to offload complexity and responsibility for you. Sometimes at the cost of control and costs like dollars right
So you need to ask yourself the question is, like, do we go with a single vendor or do we go multi cloud. Just know that if you go multi cloud, then you need an abstraction layer.
Could that be Cooper daddy's. Sure. Could it be virtual machines. Sure. That's not a problem. Do we need to stick with generic services like MS SQL and my SQL and whatever. Sure, you can do that.
Do we need to do a third party like Mongo DB Atlas and just spread MongoDB love all across our cloud providers and we'll just use that. Sure, you can do that. Just know that there's cost for all of that but
Be prepared to leverage cloud as much as possible. And if you put private cloud in place, and there's a very there's a different conversation. You'll still be using the same open source technologies. But is it API driven does it actually support a cloud API driven approach.
So the second question is that, you know, assuming that cloud and microservices can go together like peanut butter and chocolate. They can be unable to serve each other.
How far do we go right. Do I go ahead and go to dynamo DB, which is a no SQL data store and I do auto scaling and I get into DAX which is the in memory data store that can sit on top of dynamo dB.
Do I go far down the rabbit hole and get single millisecond performance from my database for my API.
Or do I go with an abstraction layer like Cooper daddy's which honestly is not going to get you single digit millisecond response times. And when you run data stores on Cooper daddy's there's gonna be some complexity because it's got state.
Do I do that because I need to control and I want to run multi cloud.
Something to think about. So, and if you do go multi cloud. How do you minimize dependencies. Well, you got to
Abstract as possible. So something to think about when you're designing your infrastructures, is how much is this decision going to lock you in, but you want to go cloud native, even if it's like, for example, VMware or
Not open shift OpenStack or any of the other kind of private cloud providers that you can look at
Now this is going to be a little bit of a mouthful, so I'm going to skim this just know that 12 factor apps 12 factor.net
Is another aspect that you want to think about when you're looking at microservices at designing microservices, is that obviously you want to use like revision control.
I hope you all are, although I still have run into people where it's like, yeah, well we're using kind of older revision control. It doesn't really allow us to track and that's fine.
evolve towards revision control to make sure that you're isolating and declaring your dependencies, hence why you want to store your database with your micro service and not let anybody else. Talk to your database.
So they can't record database because that's the dependency.
Want to make sure that your configuration is stored in the environment and you want to get to infrastructure as code in that context to see one in three kind of together right
Make sure that you can automatically provision deploy test automate do everything you need to with your micro service.
Obviously databases are backing service. You want to treat them as an attached resource, but there could be other resources that are attached, like let's say you had a Search Database. In addition to a an LTV database that's a dependency bundle those together, right.
Make sure that you're using separate build and run stages.
Right. Make sure you're executing your app is one or more stateless processes, there seems like there's one missing there. You want to make sure that you scale out via the process model. So do multi threading. Do you know sub processes as needed.
And then you want to maximize your startup time with fast startup and graceful shutdown. You want to fail fast and when you fail, you want to fail gracefully.
Reference that Netflix reference I made earlier where when you go and look at all the recommender is one of those recommendations fails, it just disappears off page.
Another thing just moves to the top, you don't actually know that Microsoft has failed, and then you refresh the page and guess what your personalized recommendations are back because that micro service blip for just a second, but you didn't even know that Netflix had a service outage.
You want to keep development staging and production as similar as possible. This is one of the great battle cries, by the way, with containers is because it adds environmental item potency.
basically allows you to run stuff in your laptop, it's in a container. It's got all the environmental context and then it stays the same as it moves through right we love that.
But you can do that with virtual machines as well. And you can do that with other services. So don't let that be the only way that you can solve that problem. It just happens to be a great way to solve it.
Treat logs as event stream. So make sure that you're capturing all the data from logs as much as possible and just treat them as continuous real time events that are streaming to you that you need to take in.
And preferably make searchable store centralized coordinate, you know, the whole UTC timezone thing can really blow people's minds when they're trying to find correlated data. And lastly,
If you need administrative processes don't have the people who are doing the administrative processes on the same process that your customers are using
Run that even as a separate even micro service with maybe even a separate set of API calls that are admin only and authenticated differently and secure differently and not published.
Right, so that that's that's like an off off customer process.
12 factor apps for the way tons written. There's even a beyond 12 factor apps which I was can't remember the, the company who wrote that, but you can find lots of exposition about 12 factor apps which was actually almost like 15 years old now.
Let's see who's going to check for a second. Looks like we're good on questions will answer the bulk of the questions at the end. But I just want to make sure in case there's anything burning. So, looks like we're good this far.
Okay, so we just spent you know 30 minutes talking about designing because that's where the most important decisions are made, right. It's his
Decisions you make at the front end will have huge impacts. Years later, right. But now we're gonna talk about that evolution from designing to implementing and then we'll get to implementing in like a little bit more detail.
So just to rehash this scoping is super important. Right, so it's not enough just to write a bunch of RESTful web services intelligent talking to each other. Right.
You have to take in the you know the considerations, the runtime and operational aspects of a distributed system, especially around things like scalability.
Reliability high availability, although the abilities need to be considered for robust microservice design. So it's not just about being in a single business context on one dimension.
It's about how do you design for failure. How do you loosely couple, how do you scale. How do you deploy. How do you test all amazingly in scope for a robust micro service design.
You know, how do you distribute transactions efficiently, are you calling a bunch of other services. Well, you might need to catch that.
Especially if there isn't frequently changing data or even if it's changes once every 10 seconds, but you're making 1000 calls a second
You might want to catch that, because that might save you 10,000 calls. So you want to think about distributed transaction efficiencies because
When you go to microservices, you're trading intro process calls memory calls for over the network calls and an increased amount of complexity.
So make sure you're thinking about you, how your micro service has to make all these calls to other services. And if there's dependencies there, but both in how you call and how you are called think about offering you know a way to catch some of those context switching mechanisms.
Service scaling obviously is important. A lot of those mechanisms will be handled by like
Programs like Cooper 90s, or auto scaling inside of VC to or skill sets inside of is your like whatever it is that you're using. Right.
You want to make sure that your service can scale and be deployed in an almost automated and dynamic fashion without user intervention.
So that's an important consideration.
Data consistency is important and making sure that you're the only one who can talk to your data store is incredibly in scope from going from designing implementation.
So when you actually implement a data store. Make sure that your, your API or you and your administrative API are the only ones that can talk to the data store.
If someone else can talk to your data store and just trust me on this. I know this from hard experience. They will record your service will fail. And then you'll realize that you probably shouldn't have given them access to your data store to avoid that mistake you leverage my my failure.
And then you want to be clear about what your service availability is
If you're doing a recommender. For example, you can be like, well, one out of every hundred calls. We're gonna fail.
Okay, that sounds great. As long as you know. Okay, so then how is the presentation layer going to handle that failure if that's your published SLA right
But you do want some resiliency defaults, especially if the business needs you to be resilient if every time you look at Netflix this page and all the sudden it was like, well, it's not loading.
Like well that would be kind of a horrible user experience. But if components of the page fail and they're not necessarily impactful to your experience.
That doesn't matter as long as I'm seeing what I'm, you know, things that I'm looking for. I'm looking for streaming videos and episodes and TV shows and movies.
Then I'm probably okay. Now when I start going to look for something specific. And I can't find it. My resiliency requirements might go up.
So, and, and to say this is that, make sure your memory, you're minimizing service disruptions, especially as you go through the lifecycle of deployment and retirement and new feature delivery and maintenance.
Try to make it as invisible to the user as possible. Ideally, the user never knows that you're damn ever
I didn't mentioned this earlier is that Eric Evans wrote a book called Domain Driven Design, I believe it was in 2004 2005 right. And the idea here is that it's still about the domain model of focusing on on one business contact one bounded context as possible.
Why are we talking about the bounded context again.
Because you want to make sure that you don't cross the bounded context. Again, if you're doing billing than just do billing
If you're the billing teams credit card processor and that's your micro service that don't get into G pay or even like PayPal or ven most don't get into those guys. Your, your focus your bounded context is just on the credit card pieces.
So you want to make sure that scope for that. Right. And you can use something called a context map. Use the good from a business derivation
To show which so sub domain is yours bound that context. And then there's your micro service. It all starts from the business. That's how you derive the microservices context. So just remember that.
Remember that the internal models of your microservices. What they do what they access the data they need are all controlled by their bounded contexts.
And external models like the API's are used for this interest service communication. So, what you published by the way might be very different than what you do internally.
And that's good because we want that abstraction layer. It's like an extension of the facade pattern.
We want our customers to deal with the facade that we've put out. We don't want them to actually see what's going on on the back end, we just give them what they ask
Right. You know, most of us don't want to see exactly how the sausage is made right we don't see how our
Food is made now because we don't. We clean. That's what the health inspector reports where we can trust that right. We don't want that.
But at the same time we're like, I just want to stay as long as it meets health and i don't i don't really care just give me a steak. That's all I want.
I don't want to know about the process that you went through. I'm not super interested in that. And that's the same with our API's. We want to talk to the API, get the data that we've asked for and move on. We don't care if it came from cloud MongoDB Java. We're not doesn't matter to us.
By the way, this last statement. Look out for a blank, blank. The bounded context that are kind of crossing over or bleeding into each other.
That happens a lot. When you have contexts that are kind of crossing over each other. Caching is going to be your friend. If you keep pulling information and your own billing and keep pulling from profile.
You need to start thinking about caching data. So you're not pulling from profile so much, just as an example of two services.
It is worth mentioning that most startups are not starting with microservices, I can't, I think, was to Kelsey Hightower was tweeting back in 2018, he said.
Man, I, I feel really bad for all these startups who are doing microservices on Cooper Nettie because they're paying a high complexity costs right off the bat for something that isn't necessary for the business.
Right. But he also build the way that same year tweeted and said, hey, if you run communities and you think you're going to get a relational database service out of the box.
He's like talk to me in a year and a half after you put 12 people on that project. Right. So where do you start well I think going directly to a microservices architectures risky.
Instead, start with a monolith. And the minute your monolith starts getting complicated
Refer to my reference to Ward Cunningham from 2003 where he was like technical debt is that feeling you get when you go to make a change. If the feelings. Good. You're like, yeah, we can make changes to that thing all day long.
Then your monolith has not yet become an anchor. If you go to make a change and you're like, oh god, we're going to talk to this module in this module and
That's just like super complex and we're going to integrate with this team and that feeling of complexity.
That's when you want to start slicing things off. Don't get me wrong, you can design your monolith to have service boundaries inside of it even inside of a single process.
And then later on. You just segment them out. You just put an API in front of it, have them make API calls and I make that sound trivial. It's really not.
But as long as you're thinking in that direction from the moment you design your model, if you can get to microservices a lot easier. So the bottom line here is that has complexity starts to rise start breaking things out in microservices.
By the way, this picture comes from Martin Fowler. I'm like, why is there a be there. Like, why is there would be in this picture. I'm just like, Okay, fine. Moving on.
All right, there's couple other things to think about when you're moving from designing some limitation, right, is that
You want to save a rapid feedback and change you want to reduce inertia, find a balance between using managed services and off the shelf products and off the shelf libraries, instead of rolling your own
There needs to be a balance there I was working at a company last year and they decided to create their own Cooper Nettie his
Identity access management policy engine. They basically wrote their own identity provider and there were like five in the enterprise that we could have used
And, of course, that whole project failed because they speak sentiments doing identity instead of focusing with their core business was, which was actually something else with IoT
So don't reinvent the wheel use with everybody remember the business doesn't necessarily want you to write anything if it already exists.
Remember, keep the business in mind. Keep the customer in mind. So eliminate accidental complexity.
And then, you know, make sure that you're relentlessly improving your work and auditing what you do and refactoring and improving that actually makes the work better, faster and keeps the technical debt out of the equation.
Remember, we want you to loosely couple. That's what the API's are for, again, if you're relying on another service. Make sure you look at caching. If you're relying on another service too much to cash.
Then you might need to replicate that data into your data store, somehow, don't worry.
Your DevOps sorry operations folks will gladly help you figure that out, or UDP as if you still have them. I don't know why dB is no longer cool where there was a data engineer. Now, but it's still a necessary function.
So remember, crossing context boundaries as I just mentioned is expensive. If you keep having to talk to these other services to function, then that's a dependency.
Figure out how to minimize that as much as possible.
Now, I've been talking about all this decentralization, remember that you're still going to need
Centralized authentication centralized logging, you might actually need single sign on because do you really want your user to login to all of the different micro services at the same time.
Probably not. That's going to be a bad user experience is going to drive them crazy, you might not want to be responsible for all of the presentation layer, right, because if you do one team to do that, then that will be their sole job.
That might be good, so that you can just focus on delivering data and not focus on the presentation layer because keeping up with Firefox, Safari and what was everything so edge. You know, like in the new version of
Microsoft browser. It's like, do you really want to be in that game. If you love it. Awesome. Go for it. If you don't, then just focus on back end services and supports presentation team.
Auditing session management caching that might all need like session management, do you want to be responsible for tracking someone session throughout the entire life cycle.
Maybe there's a session micro service, whose job it is so that you can retrieve session state or maybe it comes across the wire. Maybe it's a cookie. There can be other ways to approach that
So just know that you do need to figure out where they're going to centralized or decentralized client access that can always be a concern.
Again, potatoes, potato. It just depends on what your team can support most of the models. I've seen have gone to a centralized model instead of the decentralized model.
Especially since most products are going to have about 20 microservices that support them. Don't want to do logins for each of that you want to centralize that as much as possible.
I mentioned the facade pattern already, which basically, it doesn't as the abstraction pattern. It's where you interact with the API.
And what goes on in the back end. You don't see, which is awesome. There's a lot of different micro and macro iterations of that from a code standpoint.
versus, you know, a client interaction standpoint, but basically it's about going to a proxy, who then acts on your behalf. And so you want the client to interact with the proxy and you can do whatever you need to on the back end to make that proxy work.
Or what about state. We've got about 13 minutes left a little less because I'm gonna make sure I leave room for questions.
How can we maintain state. So we got two main options. One, you can maintain it in a database, you can have a client, send it. But the bottom line is, is that if you need state, you're going to be the one to maintain it. So you're gonna have to figure out that concern.
You know, again, you can use a caching solution or you can use a more permanent data store and the technology doesn't matter because that's why we're using microservices you use what makes sense right
I didn't mention this earlier also, is that micro friends are your friends. So having a presentation layer you hopefully managed by a team that's dedicated to that.
Is awesome because it allows you to present data to them and they in turn can use these micro us to present back. So you might have to present on micro UI within a presentation context, but you don't have to do the whole thing.
You don't have to worry about browser browser compatibility or any of those pieces. Your job is just to present a widget, in a sense, a micro UI concept back to the frontier of your app.
And so that's that's awesome because front end developers and back end developers. I know there are people who are full stack, but typically people are better at one thing than the other. They're really good at present presenting on the front end.
And they really specialize in high end low latency transactional backend services.
So it helps with basically breaking up that kind of monolithic presentation layer and that way you can cover mobile, you can have a desktop.
You guys lead that team focused on it and you can be less concerned you seen present your widget and your widget will get handled by the presentation team.
Talking about designing for failure. So making sure that you're ready for your components to fail. And how will you gracefully support that.
And then you know application frameworks that support it. Right. There's a bunch, like so.
In many cases, by the way, if you implement, like for example spring boot or you know something older like drop wizard or some variation there of flask even is that these libraries and frameworks will come with microservice ready implementations
Oh, yeah. So here's some things about spring work and drop spring boot drop wizard spark for like the Java community node has several frameworks, you know Python has several frameworks all supporting micro service oriented application frameworks.
Okay, so here's, here's a quick summary of some best practices one use immutable API's doesn't mean you can't add to them, but they're not mutate IV.
So if you offer pizza hamburgers and tacos.
You want to add sushi in my earlier reference, you can add sushi. You can add whatever you want to the equation, but don't remove what you've added
Unless you give it a long communicated cycles. So people can refactor their apps, but it's still better like if you want to get rid of tacos.
Just point tacos to whatever the new thing is maybe the new thing is to keep those
You know, you're going to go to like a taco burrito. That's fine. Just make those API calls. Go to the new new area, but don't get rid of the old ones. If you can, because remember, that's a contract.
And people have designed for that contract and you don't want to break the contract that's that's a bad user experience or a bad internal team experience for them. You don't want that.
Stick with one business domain per service, not an M service that's a typo on my part, I'm not making up a new word. It's just service, right.
And then database access is only through an API for external services so nobody can talk to your API.
I'm sorry to your database, except for your API and your API only so nobody else gets direct access to your database.
Cross Cutting concerns should be centralized that's the recommendation so security presentation layer logging caching right session that should all be centralized
Make sure your infrastructure team right your structures ready for distributed computing. If your network is flaky. Don't do microservices. That's not going to work for you fix that first and then go to microservices right
Use frameworks, right. Don't reinvent the wheel. People have been doing this for a long time. And remember that when you do distributed computing when you go from monolithic microservices.
You're going to need more observe ability and traceability than you've ever needed before
See, before it was just an inner process and a memory call you were just calling another module in memory. So there's no problem. You don't have to worry there's no network there you just going from memory, a memory.
That failed. By the way, you would have seen it right off the bat. But now, because you're running across the network. And that network can be 10 gigabits and speed.
That service could still fail. Do you know in that service fails and how does it heal you need configurable talk, you'll be able to toggle observe ability to go from noser of ability to ridiculous amounts observer ability in one little turn or flip of a switch.
Make sure you're using CI CD pipelines, make sure that you are using one database for micro service, or at least one and make sure nobody else can access it.
And then remember this. And this is a very opinionated statement, but I will make this clearly
Conway's Law basically says that you're going to design services. The same way that your organization is communication structure works.
So if you were designed in a monolithic way from an organizational standpoint, you will design services in a tightly coupled monolithic way.
If you want to change that you've got to reach, you're going to change your organization.
At least slice off one group of people who are going to work on one micro service and make sure there's security operations architecture and developers in there along with some testers, whether that's QA or whatnot.
And that team needs to be to go independent and you need to organize that way. If you don't, I promise you, your mindset and your organizational communication structure is going to inhibit your ability to go to microservices.
At the end of this presentation, by the way, is a bunch of useful links and deeper dives into JOHN LEWIS and Martin Fowler.
And all of these people who have talked about these topics, because I just gave you a fire hose of information.
And I just want to make sure that if you want to go deeper. Here it is. So you can actually dive into all of these concepts even more.
And answer questions like, how big is a microservice and how do you do battle tested standards and what it, what do you mean by circuit breaker.
Right or synchronous calls will sequence call synchronous calls will really slow you down. So make them a sink. If you can, but there's useful links here at the end of this deck.
So we do have some recommended training. So, you know, we have basically a technical introduction to microservices architecture training for microservices.
A micro services engineering boot camp. And of course, if you really want to dive into the underlying technologies that nowadays are considered the modern supporters of microservices.
You can get right into Cooper daddy's Docker and will you play with Maven and Jenkins and some of the other tools that can help you get to a microservices implementation.
As always, if you need more information. Are you looking for any training on any topic, you can visit exit certified com to get started, there is a plethora of classes and in every technology that you're looking for. It's there.
So all right, so we're at the end of our presentation. So now we're going to open the floor up for any questions that have arisen.
Michelle Coppens :: Webinar Producer
Awesome. Michael that really was a intriguing lecture. Thank you so much. There is one question already queued up on any high level UI design recommendations for interactions with this microservices architecture.
So Enrique let's see any high level UI design recommendations for interaction with this microservices architecture. I'm going to just say that right off the bat. You've, you've no I don't really have a good answer for that because
I mainly work on backend services and I've avoided.
The, the, the, the treacherous front end UI. So if you work in that you've got my admiration and respect. Right off the bat, because I don't have a good answer for that I
Have seen a lot of teams implement the presentation layer and do the micro UI layer, but I have not done it personally. So I don't have any first hand experience. I can talk about there. So I apologize, but I don't have it. So kudos to you for tackling that because it's it's a very
From my perilous domain having to keep up with all the standards around the browser somewhat not
Michelle Coppens :: Webinar Producer
There was a comment in the chat window from Alex asking if the slides and video will be provided so that they can pass it off to their co workers.
And so we will be sending out a PDF copy of the slides and we're going to share a recording of the webinar. So we'll send that out by the end of the week. And if you want to pass that off to your coworkers. I think that's great.
There also was another question by anonymous attendee who wanted to know if there's any processes to help figure out what the bounded context should be
So there is a reference link in the previous slides that will talk about bounded context from a process standpoint, I recommend that you grab a copy office, like, you know, Safari books online or whatnot of Eric Evans is Domain Driven Design.
That, you know, the main process that you're looking for is the context map. What is the value stream flow of all the processes that go from customer through the business back to the customer.
And when you identify those value streams from a business perspective, those can really help you figure out what are all the different components that make up that value stream.
And how can those be microservices out, for example, you heard me talking about inventory and billing and profiling.
So you really want to start with a value stream map that derives exactly how customer goes into the business and how a customer goes out like what they get out of the business.
And that that process of deriving a value stream will help you figure out exactly what you need. Now, most of the time we talked about value streams in terms of like
Back end processes like how do we deliver like virtual machines or containers or whatnot, but it's also a very valuable to start from the customer. All the way in to the value that they derive from the business.
All right, any other questions around microservices about implementation design architecture or whatnot.
Michelle Coppens :: Webinar Producer
Very thorough presentation again. Thank you so much, Michael to all of our attendees. Thank you so much for taking some time out of your day to learn a little bit more about micro services.
Visit our website to contact us to find out more about training to learn about some savings that you can save on right now and we'll hang out here for just a couple more moments, but if that's all then thank you so much. Yeah.
Thank you, everyone. Thank you for participation.