Duration 39:05
16+
Play
Video

Migrating from a Monolith to Microservices (Cloud Next '19)

Martin Omander
Program Manager (Developer Advocate) at Google
+ 1 speaker
  • Video
  • Table of contents
  • Video
Google Cloud Next 2019
April 9, 2019, San Francisco, United States
Google Cloud Next 2019
Request Q&A
Video
Migrating from a Monolith to Microservices (Cloud Next '19)
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
17.62 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Martin Omander
Program Manager (Developer Advocate) at Google
Adam Ross
Senior Developer Programs Engineer at Google

Martin Omander works for Google in Mountain View, California. His job in the Developer Relations team is to help developers build better software, and improve Google's Cloud Platform to make it even better for that purpose. Before Google, Martin worked at a string of startups in Silicon Valley as a software engineer. In his spare time he is an amateur game programmer.

View the profile

Adam is a software engineer in Developer Relations working to make technology simpler with serverless. Prior to joining Google he worked in many roles as an engineer, consultant, solutions architect, platform planner, and tools tinkerer.

View the profile

About the talk

Microservices enable development teams to be more agile, but it’s hard to break up an existing monolithic application or to run many services. Come to see a time-lapse refactoring of a fictional monolithic web application into decoupled services. An incremental approach and GCP serverless products for hosting, communication, and storage come to the rescue. We will explore how to get started and use best practices for your journey to a low-ops, high-velocity future.

Share

So show of hands who here is running a monolithic application a big single piece of software. All right, and how many of you have started to split that off into smaller Services? Okay. So that's a good number of you but they're still on the table are ready to see where this goes. So today we're talking about migrating to microservices in the context of server list serverless is a great fit for building microservices because of how quickly you can get something started and launched. So here we have a cloud function. It's just a couple lines of code. I bet it's

enough to get a proof-of-concept going to have to complete microservice. Yes. It's not a very smart one. It's just sent sending some environment variables along to the requester, but that's enough to integrate with something and see if you can use microservices with your application. And if you want to deploy it that is a one-liner few Flags there for the first time but not very hard. So today we're going to follow that step and further journeying into the world of microservices with into the woods there an online camping gear store and they have been doing a

lot of great business investing in their technology to Drive Commerce, but before we talk about them too much worth knowing there an imaginary company there going to be an example for us to follow through their journey and then figure out which lessons they've learned my best apply to your own organizations and since they're monolithic application they have now is starting to get technical debt little fast slowing down. How good is pasta Kindle software. It's time for them to start looking into what else they can do. And so one of your developers test is going to lead us into those new

approaches. A shame they're totally imaginary. I really like that fact packs like to buy that. So what if the developer she she has to be stored about microservices could help us with release velocity and velocity are these microservices definitions monolith? Okay. That's what most of your applications that you raised your hand. That's what when you have a big ball of yarn and everything's sort of connected or could be connected to anything out and anything else microservices are when you have specific services that are independently built Floyd

operated and scale microservices could take requests. They could potentially call each other as well to fulfill request. Let's zoom in on one of those microservices what's inside a microservice there for things but we think are very important to tell us a different options out there. And I think that they're four things that set of microscopes a part 1 is it has an API if you're going to talk to the microservice you talk to the API no other way in it has some Computer Resources. So this is a way through actually wrong code run business logic

most microservices virtually all will have some kind of storage database file system in memory Tash something like that. And then the fourth thing is actually known technical thing. We think it's very important that the microservice has a team associated with it as well. So if this service break then we know what team to talk to if this service needs to be respected than this team has full ownership and nobody else can come in an override what they are doing. These guys are the experts on this microservice. So we going to follow tests

microservice Journey here. She's going to lay the foundation. They will build some brand new functionality as a microservice. After that test on team will take existing functionality in from the monolith and price that out into a microservice test will sit down and plan with her boss for the future of what to do with microservices in the future and finally will be song Some contemplating about what we have learned here today. the first laying the foundation doing this sort of digital transformation where you break up

monolith you change everything for the way all developers are working at your company. Also change the way all the teams are working requires. That's not a big bang that is like a hundred small brown bag lunch has a lot of explaining to people who don't know what these are getting the team on board. After that test would go and talk to her manager about I want to go to microservice route to the team thinks. We should go to Microsoft route. She her boss is Fang who is the CTO of into the woods now, this conversation can go one of several ways. This could go

to to sign and say we should break up or monolith to microservices are great. What would sang say do we have any sitio sin? The origin o? Yeah, okay, very good. I think you would say such. Oh there in the back. Of course, let's do it. Is that right? Okay. Good, so and this is a hard conversation because we don't have hard numbers. Developers. We all feel like microservices are easier to manage your bills, but but it's really hard to prove that's the case. So test buys her time a few weeks later sang

comes to tests and said the business people they want and you a recommendation engine So based on what's in the cart. They shouldn't we should show recommendations to users now test is in a much better place because me, and the team we have this great new approach that will give us greater than velocity on the for this new feature you want to build and now staying at the interested so Beth tells him more Yeah, it's great to test has this opportunity with a new feature that might be valuable but isn't mission-critical immediately cuz it could be

faster for her to build this as part of their existing application. But as a new service, it'll take a little more time to get right but in the long-term, maybe I'll be more sustainable that says approach is going to be iterative using a lean approach or making sure that each step of the way through this they made the right decisions are building the right thing initially. The main concern is will this particular approach of building recommendations as a microservice work on a technical level and furthermore. Will it work as a way of having multiple teams collaborate can the API

contract prevent having a lot more meetings as a result of having two different software systems. If we don't like meetings do we know if that works out? It's time to move forward and start to see Candice recommendation system Drive some some money. so Texas using a serverless approach in her exploration here and as we discussed earlier that has a number of advantages especially for an R&D effort like this where she doesn't have the backing of a big off steam and doesn't have a large pre-established budget serverless allows a low infrastructural management

solution and a pay-as-you-go model which means the experiments they run other experiments they pay for there are three main conserve list options on gcp cloud functions a pension and if you may have heard this morning Cloud run a new product that allows serverless containers to be rotten for now though Cloud function seems like the way to go. This is a very highly scope recommendation service and that fits with the tight focus of a function. Here's the architecture of the recommendation service. The monolith is going to make requests make requests other

recommendation service sending the product ideas from the shopping cart and the recommendation service will send the recommended product IDs back now for now for now. This is going to be a very simple system Dave from marketing has a couple ideas of what they should be recommending that day and is going to tell the development team to go ahead and deploy those recommendations. So these are hard-coded recommendations or less. Yes, but the important thing is that those recommendations eventually show up on a shopping cart page. so there's always a few

challenges from that CTO or from any kind of technical review. Can you really proceed with this will work out what if that new service doesn't respond well to slightly lower priority service asynchronous requests from the monolith with a timeout will allow it to move on if that's service has an interruption in does not respond with a recommendation. Is there a scaling challenge? Well a survivalist approach allows you to scale up horizontally quite quickly and then back down again 201 you no longer making recommendation request. Enter setup me and maintenance. Well, Google

engineering is helping you with that infrastructure challenge so you don't have to to carry a pager for the networking issues. So we're back to the code shown earlier. This is the first generation of recommendation service and it is deployed and working successfully. So without as a success it's time to move on to the next iteration. Can they actually drive some business value by iterating the service forward and making smarter and more intelligent recommendations if that works make it even better. And if not, maybe their algorithm isn't working out. So well

only recommending socks all day long. Will you do need socks lots of socks for camping? So the architecture that we have for this the second iteration might look a little like this. This is probably familiar. It's the same API as we saw me earlier slide, but because the recommendation service is separated from the monolith, it can change its implementation and get more intelligent without the monolith thing any the wiser. Now instead of test Point changes when they from marketing mix request days has access to a Google sheet into which she can

enter the recommendations using it as a quick and dirty back office application instead of tests and team didn't write a whole additional application and database to pull that off Martin. Could you show us what that looks like? Yeah switch to the demo, please. So I am now wearing the marketing hat on Dave in marketing up here. We have the URL for the Microsoft Office. The only product in the cart right now is a map. So if we hit the Microsoft Surface, it returns that if you have a map in your cart, a compass

is recommended that is because Dave has answered if if their request a product of the map the recommended product is a compass and if you have more product here. So one product listen to the math and now the one could be boots and then we get the compass and laces. So boots leads to laces Now Dave loves this because he can go in here and say well actually we are at rebranding of store. When we cool. Dave think we should be a nautical camping store send a sick person to people as a recommendation if their ass if they bought a map or do they have math in their

cart when we reload now we see that the Sextant is recommended hear this gives marketing great power. They they love how they can edit these as many times a day is like feel like Let's have a look at the code for this switch back to the slides, please. So the code to read from a Google sheet is is quite quite easy. We create an object here noticed that there is there. No Spirit of sorry. There are no passwords there. No off keys. There are no secrets and none of that stuff because that's just gave access

to for the service account that the Disco drums left she gave she added that service account as a collaborator on the spreadsheet and boom all the access to taken care of. After that, we need to create a client object and then here is actually with a call to Google spreadsheets is done. We need to send two things along as parameters as the spreadsheet idea. Of course, that's that long. I D looking thing that's up in the address bar and then the range so what columns and rows we want to read? Once you have that you have a response to state of the values object.

And in this one you have a two-dimensional array of the cell from the spreadsheet. Put a little logic and stuff on top of this and you have the service we just ran and it clocks in at how many rows lines of code was it in total? Less than a hundred lines Embassy without the 30 more for authenticating to a to an API on top of it. Yeah, nobody likes to write off invitation code. So this is a great success sang. He loves it. He says to test this is amazing. I love this approach and test of course, she wants to build on that success and

we still have this big monolith over here. Remember now test and team they sit down and plan out the third iteration of the recommendation engine. They are have a few different things that could do like machine learning perhaps could drive recommendations instead of the spreadsheet that could drive it off of the current customers previous orders. They could analyze orders in aggregate. There's so many things they could do but before that time to build version 3 it's time to break out some logic from

the existing at monolith because sand comes to bathroom. Look we are really having a problem with payments losing Revenue rent right then left. Could you sprinkle some microservice magic on payments and make them work? What will both stay here. Let's do it. This is a great way of getting more microservices into the company. So first off she looks like they still existing code for payments and I don't know many of us have worked in existing code bases and we may have seen something like

this sprinkled throughout the monolith are various payment operations that go off to the external payment provider. But also there are these weird ways were some squiggly line goes off through some weird libraries that we think it hits the payment processor. There's also this old thing where this is a piece of code that hits the previous payment processor. We don't think it's being used but who knows it's checked into Source control. There's also this other line off in a module that's not about payments at all that goes off to somewhere else and we're not quite

sure where This is the way existen code basis often look right? It's it's sort of a creeps over time and nobody really knows what's going on in all places then and nobody dares going in and delete it all so test. She thinks we can really get some Focus hair with microservices. Let's see how that would be done. And it seems like one of the biggest challenges is that payment is really critical but there's no one who's owning all those pieces for the micro service approach. You can at least have one service in the code base in the solution that someone some team can own and make sure

it doesn't start becoming squiggly to hear. We only have very straight line showing the API calls from the monolith making requests of the payment service, which does all the interactions with the payment processor that also has the nice results of being able to swap out that payment processor if you want to make a change and only touch the one service that API that needs to be thought through the what exactly are those various operations this payment service should support Well before getting into a technical design session, we need to be strategic

a technique called event storming might be used here to figure out what are all the different kinds of things. That might be long in a payment service and this requires both the technical experts and the subject matter experts to get into the room the technical experts might know specific things about the existing implementation and have a lot of insight into the internal implementation events that matter but the domain experts are going to have a much clearer idea of all the things haven't been possible to do so far or might be really important during the year that could be critical to

inform the architecture. So once you have a long list of events that all seem related to payments is time to start separating them out into two piles. What are the events you include in your payment service and what are the events that you're going to exclude is being not quite focused enough to belong here. So we might authorize payments charge a previously authorized payment refunds cancellations, but excluded from that an inventory function order status and shipping. These are things that might be intimately related to payments but are a different domain area

with different owners and different problems. Maybe those are microservices for the next exercise. All right. So sang the CTO and his boss. He's really encouraged by this now. We actually know what we're doing with payments. What is this? There's one thing missing here. There we go. There's one thing missing here today with the monolith. We are dropping some payments. Now, you're breaking out the payment service from the monolith, which is great, but we could still have this result of this problem that we

have with the one with today. So what if someone live with Sans on authorization request like authorize this credit card number for $100 and somebody put a, in the wrong place in the payment service or the network is down or or they payment processor is down. Then I 500 is returned from the service. Okay, that's good. But we're still in this position where we've lost money. We have a payment that hasn't been authorized to counter charge this payment later. How how does your microservice magic fix that? Tess thinks this through

reads up on it a little bit and she comes up with solution asynchronous messaging is the way to go because instead of just having a talk directly to the payments can go through clouds tasks, which is a fairly new product and the Google Cloud platform. Let's see how that would work just like before firing forget needs to do. This one's only with Dan send that message on to the payment service. Somebody put a coma wrong. It was a network error. Whatever this a failure the

payment services weld ad Services returns with 500 silver ever. Now hear things are different start going different from previous Slide the cloud task component doesn't give up if we keep resending that until there's a success and then as soon as a as a status code returned from the service is in the 200s. Cloud tasks knows that okay, I can lean back. I don't have to send it any more time Martin. How long will it keep retrying those those requests? Yeah, you can set it but at the maximum it can be 30 days and you can set it to Shorter.

If you want to you can also adjust the exponential back-off Behavior hair. Okay, so as sign says good good. That's done with work. And you know, I talked to the office team that really like this microservice approach. Bought test. Describe functions we had before JavaScript. We uploaded them to Google. We didn't really know where and when they were running up seems I want to be a little more Hands-On. I have more control of the stat care. How can we get that with your microservice approach test? Just think about it until I

actually do they want containers and thanks containers containers that usually a lot of work. We want your toddler lower abs. You've been telling us about that serverless has what the control of containers how would they do that? That test doesn't we have time to stand up a kubernetes cluster today? Luckily. There's a new solution for this Cloud run a new beta products that marries the worlds of server list with containers. You can wrap your service in a container that in a dockerfile build a container image

throw it at the cloud and it will answer if you request and then if this service would keep growing and and the into the woods Ops Team wanted to get more heavily involved Cloud 1 on GTE would allow them to manage that kubernetes cluster and move those containers over as they deploy them to the new location. So using Cloud run, we have all requests coming in from the monolith hidden Cloud tasks now as way to ensure the resiliency of the system and then Cloud tasks will pass out the pace of the requests to Cloud run which

will then send them on to the payment processor and store status events in crossfire store a unstructured serverless storage auction. What do you mean when you say server list for the database their item, you know, a lot of database systems aren't really serverless and serverless Computing systems, like loud run or Cloud functions are going to scale much higher than a typical single instance be able to go. Slots with fire store comes in it also has some nice features like a venting on updates. So you might wander are what kinds

of crazy hijinks do I need to get to in my code to build the cloud run service? This is a pretty simple almost hello world like application written and go that is going to respond to any request with payment approved which is how we all would like payment processor is to authorize our credit cards. So there was no Cloud run specific code there that I could see. No, there is absolutely none. The one wrinkle. Perhaps is at the Port that you're a CDP service needs to bind is going to come in from a port environment variable which is a little unusual but it's

still flexible and you can override that has you need to So this service needs to be wrapped in a dockerfile a dockerfile is a relatively straightforward package manifest using industry standards around how containers work via gke or Cloud run? And this has two stages a little more complicated than those darker files, but this has a build stage which is going to compile Argo code into a binary and then it production stage with poles from a stripped-down variant of Lenox called Alpine copy in that binary and then run it whenever this container has

started up. Deploying is to commands here one using Cloud build to take all of this service and dockerfile uploaded to Cloud build to have a container image prepared and sent on to Google The Google container registry. Then to deploy g-cloud beta run deploy takes that container puts it into Cloud run and starts you serving. I have found that the first time I pee a little bit slow, but most deployments take about 30 seconds. So that's service ready to go. Let's start rolling out into production now as a whole new service and doing a mission critical function, you might not

want to have it immediately take over all Payment Processing. So the monolith is going to need to be slightly adjusted to send just some of the traffic to this new service. That means unfortunately going into all the gnarly old code and making adjustments there. Hopefully, you've already got an audit in place to figure out where all that is so it can be deleted. So they deploy they do the canary release. They send 1% of the traffic through the new payment service works great. They send 5% through the new payment process payment

service in first grade 10% No payments are dropped everything scales beautiful. The Ops team is happy because they have containers and the magic of server list. They seem to be a very easy roll out. But we all know but there is no such thing as a trouble-free rollout. There's always something that doesn't go exactly like you expected. In this case Talia the controller we've seen her before she comes into Texas office until after they ramped up on Friday.

She comes in on reports of broken. Why is that have to start looking at this closer and sees that I one of the report's actually has two pieces of data one piece lives in the monolith and other piece now lives in the payment service there before when everything lived in the monolith, it was far easier to run this reports because both pieces of data or in the morning. How do we fix this this by the way if you've been working on migrating to microservices, you will have seen this problem in one form or another or if you haven't yet you soon will visit

state of fragmentation big problem, especially for reporting. So, of course the problem here is we have the date over here on the far left. And on the right is Talia once our report, right? Well turns out test looks into this and it turns out that cloud firestore has a triggers so whenever something is written so she can trigger build a new service and ETL service that is triggered. It can sanitize the data. It can do some like data transformation and then put the data in a date on Lake of reporting reporting

service situation. The monolith has an existing reporting module one needs to be repointed to v data lake. So it sends its transactions and its orders to the date. I like know. All the data is in the date elected reporting service. This is kind of like in the morning of the days. They probably ran a separate reporting server. This is the equivalent in Surfer less land microservice land and build a reports off of that so reports for a few days. It was not idea what they had forgotten about reports when they did the event storming but they didn't lose any money. Black

Friday rolls around now we're running into a big problem sang goes into test office then say all the effect called to the payment processor all hands on deck. What is going on? This is something that if you're migrating to microservices, if you haven't run into this sort of problem before you soon will the problem here. Of course, it's you have a chain of components talking to each other and the they all have different scaling characteristics. So some of them scam very well and others not so well, for example,

they might have a contractual rate limit with a payment processor. You can only send one transaction to Second something like that. You might also I've seen it if the component on the far right is a SQL database that's not serverless and doesn't scale as well. You might have seen it if you connect to an HR System or a CMS the system or other system that can't handle the kind of load that server can handle. What do we do? If you read and check out the literature, you will see lots of thoughts on how to fix this like you can write all these codes to

write a circuit breaker component or you can Implement back pressure that leads back through the ripples back through this chain. There's so many things you can do most of them involve a lot of coding and we all know if you write a lot of new code to pick something you might fix that you will also introduce a lot new of new box. Then test remembers they picked Cloud tasks. Cloudtask actually has this norb you can turn you can adjust the rate. So the monolith can throw any amount of transactions per second at tasks pasta loves

orbit. And then it will only send out as many to to Club run as many as to ask to so Beth goes in and checked the cloud tasks console and she sees that oh my gosh, we have a lot of backed up tasks here 2500 transactions are sitting there waiting to be authorized store charged. Ask because they using Cloud tasks. They can go in and change turn that knob at that Max tasks dispatched per second to one. The default is 5 but turn it down to one now. All of a sudden there was only one per second to the payment

provider the payment provider except the traffic and will take after about 45 minutes or so that will work to this backlog. Excellence tests if it's still a little shaky shaky shaky enough over this but this is actually great job any major transformation. Any major migration will have some hiccups along the way this microservice approach. Let us move faster and experiment for he loves it. Test for her part. She's just very happy that this worked out. Another test has been undoubtedly promoted to Chief

microservices scientist of into the woods. It's it's time to start thinking about a more deliberative approach to how they do microservices in the future. So 1 lesson that she might have learned from all of this. Is that a microservice is a good fit for well understood problems a user profile service might be easy for anyone to understand anticipating advance. So maybe that can be created but for harder challenges for areas that need a lot more Innovation and exploratory development trying to stay on the path have a micro service might be might be a source of slowdowns might get

in the way a little bit. So it's important not to always be too focused on building a microservice on the things you don't yet have a have a Mastery of Moving from their sign and test they might have talked about how many microservice to microservices we want to have. So we have a thousand by the time we're done with all of this. Well feel that out as well move a little bit more slowly. You see the the trade-off of microservices is really between developers and operators release developments in operations. When you have a small service, it is

much easier for developer to really get into all the code and developing expertise in it. And so when you have more small Services development complexity might go down but as you add more and more services and more interactions between them you start to gain more operational complexity more deployments more Cascade failure possibilities in hard troubleshooting. So there's a sweet spot in there that trade-off is going to be very unique to every organization because it's very particular to the people. Do you have more senior operations Engineers or more senior application

developers between those two you'll find your sweet spot now with a serverless approach where you take A lot of that Ops overhead and pushed it onto the cloud. Deadline for Ops complexity will flatten a little bit. And that means your sweet spot can slide over and it becomes more reasonable to have a larger number of microservices In Your Arsenal. So they've been adding new microservices and splitting some off from the monolith. Each of those Services has a

stakeholder. This is an owner whether it's on the business side or otherwise that understands that service and the role that technology in the company. They can be a champion of that technology through the rest of the company, but they can also be an ongoing subject matter expert for the service this kind of direct line of ownership also prevents a lot of confusion about what priorities are for an individual service. So, what did we learn here? What are the what are the lessons test sits down and think carefully about this. This is lessons.

We hope you can apply for you and your organization's one is Conway's law. This was this was created by Melvin call Con-way. He wrote it down over 50 years ago. It is as true today as when it was first written down any of you was worked on systems or if you worked on a website for an organization you've experienced that. What this law is saying is that if you have a certain type of organization organizational structure that organizational structure would lead to any system that you build will be a mirror image of that

organization. You've seen this one building websites for companies. They wrote the website hierarchy and patriarchy and tends to follow organ or the org chart. So if you have many small teams, you will get many small microservices. That means that you can actually do an inverse Conway maneuver here. It's what if you want small Services over there on the right, then you create many small teams. If you want a big monolith you have just one big room full of developers and everybody is on the same team.

Next observation is that weight lifting is really hard if you do it by yourself, but weightlifting becomes a lot easier if you have like five or six of your friends to help you so the monolith is really doing heavy lift here before but it's far easier when the other services are helping out as a matter of fact the monolith, my doesn't have to lift. I do as much work here because the other services how about you might even discover that the Mona Lisa is home sick one day and can't come in a lift weights and the other services can sort of let do the lifts and eventually you might have only

Services that's far into the future for into the woods, but it's something to consider and think about it's also something that we need to be a little careful when we talked to the monolith team about we don't talk about how we can shut down their stuff. As a matter of fact, this also has another name that you might have heard of that was a little too confrontational for slide. We felt Martin Fowler calls this the Strangler pattern. This is where you have a tree in the forest and all these Vines grow up around it and stuck energy from the tree in

eventually killing the tree and then will the wind surf their butt lifting. Then you need an intrapreneur to an intrapreneur is an somebody as an entrepreneur mindset, but works inside an organization. This was Tess in this case. You need that intrapreneur. You also need that opportunity and this case it was the recommendation engine. and that set them on the path to microservices, so you Can be the intrapreneur in your organization. Keep looking for those opportunities.

Cackle comments for the website

Buy this talk

Access to the talk “Migrating from a Monolith to Microservices (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “Google Cloud Next 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
163
app store, apps, development, google play, mobile, soft

Similar talks

Dan Sullivan
Principal Engineer/Architect at New Relic, Inc.
+ 1 speaker
Mike Truty
Technical Curriculum Lead - Hybrid/Application Development at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Emilio Del Tessandoro
Senior Software Engineer at Spotify
+ 1 speaker
Sandy Ghai
Cloud Bigtable Product Manager at Google Cloud
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Gabriela Ferrara
Developer Advocate at Google
+ 4 speakers
Dave Nettleton
Director Product Management at Google
+ 4 speakers
Alok Pareek
Founder/EVP Products at Striim
+ 4 speakers
Codin Pora
Director of Partner Technology at Striim
+ 4 speakers
Tobias Ternstrom
Director, Product Management at Amazon Web Services
+ 4 speakers
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Migrating from a Monolith to Microservices (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
567 conferences
23025 speakers
8619 hours of content
Martin Omander
Adam Ross