Kong Kong Summit 2020, 15 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Enter the Next Level: Migrating to Cloud Native Platform

Description

Organizations are moving from centralized data centers to distributed cloud native platforms. Due to the complexity of such a migration, an organization would be running a hybrid multi-platform environment which spans from the old to the new world. It starts at the edge of a system, using functionality provided by an API gateway or platform. In this session, Daniel Kocot will discuss:

- Strategies for application modernization
- Best practices for happy path migration
- How an API platform can become part of the migration process

A

Welcome to my talk about entering the enter the next level migrating to cloud native platforms. When we think about cloud native platforms, we have certain things in mind. Normally.

A

We think about cloud native, we think about architecture, so we mainly think about api gateways service measures. Sometimes we have an opinion about the people in the project regarding cloud native migrations, and afterwards we are always thinking about observability all things behind that. So in this talk we will just spot the different things around cloud native environments. So what is cloud native cloud native is about distributed systems.

A

So when we look at the literature and find something from charles swenson and janosovic a distributed system is a system in which individual computers are connected through a network and appear as a single computer, total simple, totally simple.

A

So when we go further, we enter something called the cap theorem, which is about consistency, high availability, tolerance to network partitions and so on. So it's more on this distributed thing.

A

Normally, when you think about a cab theorem, you only will achieve two of the three ones, so mainly you will have consistency and high availability, or you will have consistency and tolerance to network partitions and so on. So this is what you can achieve when we also think about cloud native. We got mentioned the 12 factorials so often, but what is a 12 factor? App?

A

A 12 factor app consists of 12 steps to develop an app. You have a one code base.

A

You have isolated and explicitly declared dependencies, you store configuration in the environment and so on and so on, and you even think about concurrency logs admin processes and so on.

A

When we also think further about cloud native, we mainly hit containers containers are everywhere. So even on the picture, you see a lot of containers so when we get into adoption to what we call cloud native, all of these containers on the picture can have something like a little application or a bigger application, and so on.

A

So when we have this container things, we need something to orchestrate some, so we need orchestration and when we think about orchestration, we want to provision and deploy these containers. We want to talk about resource management, health monitoring, scaling, providing mappings to connect to networks, and even we will think about load balancing and the one thing we have when we think about orchestration is everybody talks about kubernetes kubernetes was open source by google in 19 2013 and every cloud provider has an hubernetes offering, so it's mainly a standard.

A

So normally, when you talk about kubernetes, you always think about aws, google and azure and what they offer for this purpose.

A

But what is cubinitis humanities is just a deployment of container containers in pots which are connected to a replica set and when a request comes in a service connects to the containers in the pot or to the pot, and so there is always this part, which normally is not seen on the other side.

A

But even when we think about cloud native, we saw we have kubernetes as an environment, so we have to get into this environment, so we think about how to get there. The easiest and sometimes the hardest part, is lift and shift. What does this mean?

A

We talk about infrastructure as a service or platform as a service, so when we do lift and shift, we sometimes use infrastructure as a service, or we use a whole platform as a service to do this lift and shift, and hopefully an easy way, but when we also think about cloud native, we think about application. Modernization we want to modernize our application, which might be old, might be a legacy solution and so on, and why what we are talking about application? Modernization is also quite easy.

A

You want faster deployments, we want, or we have some components that need to be updated more frequently.

A

We have components that need different scaling requirements, and maybe we have some components that should be developed in different technology than the others, and even we think about application modernization when the code base is too big and too complex to handle.

A

Normally, when we think about modernization steps, we have always patterns in mind, so when we think about application modernization, we talk about the strangler pattern or we have an anti-corruption layer pattern to avoid problems with the data.

A

So this is what comes apart when we think about application, modernization as part of cloud native and the third part when you think about cloud native and not even technology but concepts, we always think about microservices, but why normally microservices are quite small, loosely coupled and focused on their area of functionality, so everything's becomes smaller, no bigger code bases and so on. We get straight through and have a little little world of micro services, but that's it's quite hard to handle.

A

When we have a lot of microservices, we have little code bases, but we have a lot of them. So we need something to handle these microservices even in this migration to the new cloud native world. So what comes up first is something like an api gateway, but what is an api gateway? An api gateway is when we look at patterns at the fir at first fs8, which is only there to masking complex and under complex, underlying or structural code.

A

So we want to hide something from others, but when we get to new definitions of api gateway, we mainly meet.

A

We mainly meet chris richardson and chris has a good definition of an api gateway. An api gateway is a simple entry point for all clients.

A

It can be handled in two ways for proxying or routing or fanning out, multiple services.

A

So when we look at this definition, we find an api gateway is in solution for at first routing, or we have a client and the gateway in the middle, and we have a lot of services behind the gateway and the gateway handles the routing to the services from the client.

A

On the other side, with an api gateway, we have a solution for aggregation, aggregation means we have this gateway and we have a client that the client calls the gateway or the endpoint of a gateway and the gateway begins to aggregate over different services and sends the response back to the client.

A

But when we think about this aggregation pattern, it's quite yeah complex, it's getting business logic into and a gateway. So maybe this is not. The good show the best choice when we think about the aggregation pattern in a different way. We can think about having the gateway and at first aggregation service between the services and the gateway, so the gateway communicates with the aggregation service and not with the services directly.

A

So all the business logic is not part of the gateway.

A

We have still this gateway possibility and we can change the api gateway all the time. Maybe when there are security issues and so on, so we can change the component in our architecture quite easily.

A

The third solution is offloading and cross-cutting concerns. What does it mean? Normally, when we have services, they have authentication authorization, they need rate, limiting retry policies. We have to think about circuit, breaking caching, compression, ssl, offloading and and logging, including monitoring. So these cross-cutting concerns or offloading features can't be placed into the gateway and the gateway uses. The cross-cutting concerns to spread them all over the services behind the gateway.

A

So we only configure this cross-cutting concerns at one place and use the cross-cutting concerns via plugins or add-ons with the services and provide the these informations to the services via the gateway.

A

When we are in a kubernetes universe, we have always an ingress and an egress, so something comes into the fibonacci cluster and something goes out and we can place an api gateway up front as an ingress controller and even also as an egress controller and egress gateways deal with traffic entering the system and do tasks like routing or offloading, but when we have an gateway as an egress controller, we control the traffic that exit the system and when we have a look at the whole scape of architecture, we see we talked about services outside the cluster we are in.

A

So we have conversation to the cluster and out of the cluster. But what is with the conversation inside the cluster? There we have another. I wouldn't call it pattern. I would call it component. We have the service mesh.

A

Normally, we have different services, maybe in different languages, and we have the code of the service and each service needs. Some communication code to communicate with other services, so this communication code is always placed in the same service, but this makes it quite complex and quite not so handy to give it all what you need when you think about good architecture, you might think about a side, car or proxy, where all the communication code between the services is part of the proxy, not part of the service.

A

So we have this java service on on the one side, on the python service on the other side, and they both use nearly the same proxy, which is coupled to this service of each so and the communication takes place between the service and the proxy and the proxies for the services.

A

When we think about this in a higher level, we have a so-called control plane and we have this data plan, so we can have different services in different data plans or different clusters, and they all can communicate between because of the proxies placed in the data plans who are connected to the control plan. This is the normal architectural architecture diagram which we saw when we talk about service measures.

A

So when we think about a service mesh, what do we really need? Yeah? There are some some things like cross-cutting concerns. We want to talk about traffic management, failure, handling security, tracing and monitoring.

A

And these are the features we can provide through the proxy within the cluster for the communication between the services in the cluster. So we can manage traffic. We can manage fail, failure, handling.

A

We can manage the security within the proxy and also tracing monitoring, and we think about again the gateway. We have the possibility to combine the service mesh with the gateway and have all the things like security delivered from the gateway to the service mesh control plan to have all the features at one place.

A

So this is yeah some kind of technology or pattern side of cloud native migrations, but we should also talk about people.

A

I say people, some people might be irritated, not talking about resources, but we're talking about real people, doing real projects.

A

So when we think about people always devops comes comes up, but what is devops. Devops is a broad concept with goals to make it quite easy in a definition it is, it should improve collaboration between development and operation.

A

It should also improve the deployment frequency.

A

And the teams should achieve faster times to market and even lower failure rates of new releases.

A

And delete time between fixes should be also shortened.

A

And devops should improve the mean time to recover so that the system is in a real, fast time available again. These are some points about devops. We have this broad concept and we have this improvement of collaboration between our roles in a development team. So there is a lot of conversation between people and it should be improved even more and through this we achieve all the other things.

A

But how can we measure something like devops, because everybody's talking about devops, you should do this. You should do that and you should build the pipelines to to get a better understanding of devops and do all the things we are always talking about tools when we think about devops, but devops is really about the people, so we need something to to measure our yeah milestones or something like that. Just to get on to see did we achieve something or didn't we and one thing about measurements.

A

There comes up the model of columns, but what is counts? It's about collaboration, automation, lean principles and processes, measurement and sharing, so the columns model helps us to to deliver devops in a more appropriate way.

A

We should collaborate all the people involved in a development or migration process. Should collaborate should talk in the end, they should share all their knowledge and to achieve this devops model automation is a need.

A

We should automate as much as possible. Not a hundred percent, but nearly 70 or 80 percent should be automated of all the tasks we do to deliver software or to do migrations to the cloud.

A

Even so, we should think about lean principles and processors, so everything should be. Has some kind of agile, so really small packages, a lot of iterations to go through and a lot of learning processes?

A

Even you can do or you can have failures in your processes. You just should learn about it and on the third step we have this measurement, we need some kpis to measure and we learned how we've things can be achieved or improved.

A

So this should be something we we can measure and after all this we have this sharing option. So so we should share our knowledge.

A

We had in a project where we did a migration to to the cloud and our application become cloud native. So we have a lot of sharing with other people and when we think about all this def ops, normally a cicd flow comes up. This is just an example where we have it's quite complex, where we have to complete the code, put it to git and then go through all the steps. Build container containers put push these containers into the private registry. Do a security scanning test, the configuration and so on.

A

After a lot of steps, we get a release or we just have a canary test and so on. So this is a whole complex, ci, cd flow. We see here where we have all the things behind the devops concept, and even when we put the cons model on it, we see here a lot of learnings in it, so the process started nearly small and it got bigger and bigger. So everything like deployment to uh kubernetes shouldn't be a nor it shouldn't be an a manual step. It will be an automated process.

A

So when we think about all the things we we achieved, we migrated to the cloud and now our applications or our application runs in the cloud. What is next, the next thing is observability.

A

Observability is about all the things which comes from the systems we monitor.

A

We we achieve observability when we made data available from the systems and monitoring. What we all like to do is the actual step of just collecting and displaying it. So we are, we need to do observability.

A

We need to make the data available from all the systems all the applications in our cloud environment, to get into a monitoring phase to monitor all the applications, all the systems. And after that, when we look at this pyramid of power, we have to do an analysis.

A

We have to analyze the data we monitored so that we have all the capabilities to have all the information to deliver better software, because when we do this- and in in this way, having a look at the pyramid of power, we can do some call it data driven development.

A

So we get all the information from the gateway from the services we combine them. We monitor. We do analysis about all the things maybe how apis were used by external clients and so on, and with this information we can build even better software to get to the next level of software.

A

Development, thank you for joining my session about cloud native migrations entering the next level by migrating to the cloud.

A

There will be an um q a session afterwards, so please stay tuned and ask the questions you have thank.

A

A