Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2017 (Berlin), 6 Apr 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Cloud Native Design Patterns - Bilgin Ibryam, Red Hat

Description

Lightning Talk: Cloud Native Design Patterns - Bilgin Ibryam, Red Hat

The way we design, develop and run applications on Cloud Native platforms differ significantly from other platforms. When working with Kubernetes, there are less concerns for developers to think about, but also there are new patterns and practices for solving every day challenges. In this talk, I’ll look at (very quickly) on a number of patterns and practices which are de facto way of developing Cloud Native applications. More specifically we will look at patterns such as:
-- Creational Design Patterns
-- Automatable Unit
-- Predictable Resource Profile
-- Declarative Deployment
-- Declarative Scheduling
-- Observable Interior
-- Life Cycle Conformance
-- Behavioral Design Patterns
-- Managed SD and LB
-- Managed Batch Jobs
-- Managed Scheduled Jobs
-- Stateful Services
-- Daemon Services
-- Singleton Services

About Bilgin Ibryam
Bilgin Ibryam (@bibryam) is a Senior Middleware Architect at Red Hat and committer at ASF for Camel, OFBiz and Isis projects. He is a blogger, speaker, open-source enthusiast and the author of Camel Design Patterns and Instant Apache Camel Message Routing books. In his day-to-day job, Bilgin enjoys mentoring, training and leading teams to be successful with application integration, distributed systems, microservices, devops, and cloud-native applications.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Please welcome our last lightning talk: Speaker of the night billion a briam from Red Hat.

A

Hi everybody in this short talk, I, want to look at kubernetes from a user and developer point of view and share with you some ideas and suggestions, what benefits it provides. So there are many definitions about cloud native, but if we look at cloud native applications in practice, these are applications that are implemented for in the principles of micro services.

A

They typically run in containers orchestrated by platforms on top of cloud infrastructure, and if we follow this definition, there are many platforms actually do qualify as cloud native today, and the interesting part is that this cloud native platform nowadays they offer common set of abstraction and primitives for developers to design, develop and deploy their applications. Just to give you an example, for example, the concept of deployment unit, which is pot in kubernetes, now exists in Apache Meadows. It exists in Amazon ECS under different names, but still offering the same features.

A

So there are new primitives for developers to design and develop their applications in this talk, I want to go quickly over ten principles and patterns and try to collect at the moment in this work-in-progress book so very quickly. The very first fundamental prerequisite for an application to become a cloud native is to be observable. What I mean by that is. The application has to provide, as a very minimum end points for different kind of health checks. That's the first prerequisite. The second one is.

A

Your application has to listen for events that are coming from the platform and it has to conform to these events. An example here would be your application should shut down when it gets sick term, otherwise it will get sick killed, and actually it is two primitives, then, to enable the platform to do things like rolling deployments and fix the problems, because now the platform can start your application. It knows when your application has started successfully. It knows how to stop your application.

A

It knows whether your application has topped successfully etc, etc, and the next fundamental practice would be to have a predictable resource profile. What I mean by that is, you should see your application or docker container, not only as a box with all of its dependencies, but more like a multi-dimensional box which has at runtime memory dimension and CPU dimension, and you have to pass that information to the platform.

A

So it can do things like dynamic placement, which means you don't have to think about placing a micro service on a single host or multiple micro services on a host. You just trust your schedule or to do the best placement for you. Next I want to give you examples of behavioral patterns. Many micro services are API driven, which means they have two things like service discovery and load balancing and in the traditional world. We had to do that as part of the application.

A

So we we needed an agent to register service in the registry, an edit agent in the consumer service to look up and read the registry and call the service in the cloud native world. All that is still happening, but as part of the platform and outside of your application, which is the important part, other type of micro services, are not API, driven but more time driven or temporal. For example, you may have to copy a file at midnight from one location to another.

A

Many of my customers have to do that and typically in the Java world, you had to some kind of timer or if you want it to be persisted, you have to use quartz or spring patch, but that means you know in your application. You have to care about the actual business logic and also the scheduling in the cloud native world. All you have to do is just the implement the file, copying part and Trust the platform to to the actual scheduling.

A

Another example here would be the different kind of clustering requirements: the services tab. The simplest example, probably for a cluster service is the singleton service, where you want a instance of a service to guarantee at all times to do that in kubernetes. All you have to do is create a port with one replica in the traditional world. It's a it's a pain and another important point. All the topics we've discussed here so far I actually now can be expressed as executable application manifest in the ML file.

A

Basically in the traditional world, all that knowledge would be scattered across different wiki pages room books. Some of that knowledge would be in the head of developer. Some of that knowledge will be in the head of all people now, all that can be written down as an executable file from early stages and tested on all environments.

A

In summary, here are the three points to take away. I would say let the platform automate all your routine tasks, such as placement deployment, health checks, three stars out of scaling, etcetera, etcetera and try to move as many any farms or cross-functional requirements from the application layer down to the platform layer. Things such as service discovery with job management, config management shouldn't be considering for developer. They should be just a given and then you can actually allow your developers to focus more on the business process and actually create great domain driven design, beautiful api's.

A