Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deliver Your Cloud Native Application with Design Pattern as Code - Jun Makishi & Rintaro Sekino

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Deliver Your Cloud Native Application with Design Pattern as Code - Jun Makishi & Rintaro Sekino, NTT Communications

As Cloud Native landscape is evolving, and many practices become outdated quickly, it is hard to follow best practices for integrating Cloud Native tools. NTT Communications has introduced a new idea to manage such integration: Design Pattern as Code. We break a Cloud Native architecture into a small portion of design pattern per context to make it reusable and composable. As this approach enables sharing a well designed and maintained integration pattern across organizations, our software delivery becomes safe and scalable. We will throw a live demo to build an application from some practical design patterns to turn it to Cloud Native application and delivery it to production safely. We leverage Tekton, Cuelang, and many other Open Source tools, and we will give all participants our insight to use those tools to achieve such scalable application delivery

https://sched.co/ZeiY

A

Hello, everyone, my name, is jim makishi and thank you for listening to our session. Deliver your cloud native application with design pattern as code.

A

So I was supposed to make a live spot to asks you some questions about how you take care of infrastructure as a code, but because this is a recording session. I will leave some questions here. Is your infrastructure infrastructure's code very organized?

A

Do you share your code to other team, or does your team spend a little time on infrastructure compared to application development? Our today's proposal will solve some of these questions.

A

The takeaway of this session is infrastructure, as code must solve consistency and reusability for infrastructure manifest and its delivery pipeline, in other words, infrastructure configurations and its digital pipeline should be managed in a consistent manner, and our answer is design pattern. As code which comes from our production experience.

A

Again, my name is yuma kishi senior architect at ntt communications, and we also have rintaro sequino who's site reliability, engineer at ntt communications as well, and he will take care of the demonstration later.

A

So before describing design pattern as code, let me introduce our company to give you some context of our proposal.

A

Entity communications is a global ict service provider which has a global footprint to provide end-to-end ict infrastructure service to customer.

A

uh These are some examples, our internal projects using the cloud native solutions. We are safety more to use software than before to meet customer needs. For example, our operation team is has built and cloud architecture to monitor network equipments.

A

Also, there is a sre team to manage containerized application and its release pipeline, and we are another sre team to support, enter and application development cycle.

A

One of the software project rindtello and I have worked on- is flexible interconnect project which offers an api to let customers control private connectivity between their data center cloud and even sas behind this api. We also use cloud native solutions and also we use infrastructures called practices.

A

So the point was we have many projects and we use infrastructures called at scale in terms of having multiple projects, but using infrastructure's code at scale. We see some challenges.

A

We try to codify everything about infrastructure following the best practice.

A

We wrote many scripts, we have a configuration managed by the kit and we expected the benefits of reusability, consistency and transparency, but the reality is chaos.

A

We see the more code-based growth, the more code got complicated and fragile.

A

There are many project specific batch scripts baked into pipeline, which makes it harder to share parameter is also our pain point and, as a result, we our code, got tangled. There are many dependencies between different tools and we finally are scared to make any changes to a pipeline. So we don't see reusability and consistency anymore.

A

Did we lack discipline? Maybe yes, but I believe it was not the only case. So what we wanted for infrastructure as code, we wanted to write code using software practice like making a module to share to others.

A

We want one interface for every infrastructure provider and we want most importantly, we want pipeline based in into this architecture design. So we propose new way of infrastructure's code named design pattern as code.

A

It is reusable and composable pattern of cloud native architecture written in a powerful language for a software developer.

A

So what is design pattern as code design pattern? Has code, addresses questions about cognitive architecture, how to deliver a cloud-native application and how to integrate cloud-native solutions. Design pattern declares all of the infrastructure provider manifest and pipeline.

A

It is a small portion of manifesting pipeline which is composable with other design pattern.

A

Specifically, we use qland for design pattern and it consists of infrastructure manifest and dvd pipeline, as shown for the resource declaration. We allow enumerating all of the resource configurations for infra pro infrastructure provider and we also have design pattern declaring tasks to be executed in the pipeline.

A

Those tasks will get a symbol to a text on pipeline. We chose tekton because it has a declarative api and each task is isolated from others. As shown in this figure.

A

We compose design pattern tasks into pipe textile pipeline.

A

Again, we use skewed and for design pattern as code using qlang. We compose multiple design patterns and generate infrastructure manifest, for example, we generate kubernetes manifest tcp azure adws manifest.

A

In addition, we also compose the patterns to generate tecton pipeline qlan is a powerful typed language focusing on declaring data it's designed for scale, and it gives us a consistent result. Composing multiple patterns.

A

So I just gave a basics of this in pattern as code. So let me give you one example: assuming we have api server, simple api support, server running on gcp cloud.

A

uh The resource configuration could be like this having ingress service deployment, kubernetes manifest cloud monitoring and cloud sql gcp resource this resource configuration can be break into three patterns, base pattern, api pattern and db pattern.

A

Let me show how we compose such patterns into a complete, manifest with base pattern. We could have a bare minimum manifest of deployment, as shown here.

A

On adding api pattern, we need to add ingress and service resource, and also we need to compose some parameter parameters to deployment manifest to route traffic to the containers for gcp resource. We need some uptime check config to check the health of the api.

A

On adding db pattern, we obviously need cloud sql instance config, and also we want to compose cloud sql proxy as a sidecar running sidecar proxy is a solution provided by google cloud documentation.

A

So this is definitely a best practice. A pattern to use cloud sql.

A

This means users just need to subscribe. The db pattern to start using cloud sql best practice.

A

Next, I will show how we compose pipelines having base pattern. We only have this very basic pipeline building image and deployed to kubernetes on the right side figure. You can see tecton pipeline definition.

A

I highlighted the task generate manifest where we compose multiple patterns to generate manifest, as described.

A

Before on adding api pattern, we may want to add a task to check api right after the deploy.

A

Task on adding dbdb pattern, we may want to add backup db task before the deploy task. Such tasks will get composed into the original text on pipeline definition, as shown in the right figure.

A

So I have showed design patterns for both for manifest and pipeline separately, and the complete api pattern could be like this. It would have manifest and pipeline in the same context.

A

So this is an example of api pattern. Implementation, as mentioned we use qlank, and in this definition we declare resource configuration and task configuration.

A

Design pattern could have parameter such as domain name as shown and in this example, we use this domain name parameter for both uptime check, config and check api task. This means on changing this parameter, both optim check, config and the task check api would get updated automatically.

A

This small example shows how design pattern as code help keeping consistency between configuration and pipeline.

A

This is an approach of similar to software development practice to make a small package to pack resource and task in a single context.

A

So finally, it's demo time, let me take handover this presentation to ring tarot.

B

Okay, uh today, we're gonna have a small demonstration to describe our design pattern as called coral concept, as jun described in the previous right. When we launched new microservice, we have to consider not only the kubernetes manifest, but also public cloud layer, resources, monitoring functions or application delivery flow.

B

So in this demo session we will describe how tech reads: deploys an application with design pattern.

B

B

Okay, this way, I will show you two steps: demo first step just deploy an application and second step deploy application and export api endpoint and create monitoring functions after this demo session. Okay. Before that, let me share my screen this one. I think.

B

Okay, after them session, the ap application is working with this endpoints. This is not working right now and also at the uptime checks. Google uptime checks to this page.

B

Okay, go to the simple application depository. This is the application label. Then target application is simple, flask app this one.

B

This just responds hardware for the user api request this one, and also I will show you update q file upload q file- is this is kind of manifest file to define which design proton you want to use in this file. You can declare application specific input parameters like gcp project, ids and gk. Clustered information called application deployment and also most important point is: you can see deployment uh uh kubernetes, manifest specs and also techno pipeline specs for container build and deploy application tasks.

B

Okay anyway, let's generate a text on pipeline using this design pattern.

B

Okay, let me follow this. Lead me copy and go to my screen.

B

And anyway, just run generate text on pipelines and apply it, and let me run first like some pipeline run: okay, okay, then uh let me show you a little bit. This generate text on pipeline shell.

B

Okay, uh this is a just simple shell script and document learning, container qrang offshore image and specify which uh resource type this type, this time specified tectum pipeline and specify application divisions and design proton revision as well.

B

Okay, okay, then uh I I will show you uh okay script and uh let me go to the uh tectum dashboard to show the uh what techno resources are applied.

B

Okay, I think you can see containability task. This task is optimized for our environment, so developer can build containers with uh tuned containability environment, and actually we leverage the build kit and using local cache like this and also.

B

This one deploy kubernetes, then I will show you the compile step.

B

Okay, actually, in this previous uh shell command, we generated uh text on pipeline resources. However, in pipeline uh compile tasks generate kubernetes manifest of application based on design pattern. I will show you all this one. I think this is actual uh text on task step and specified upload the q file and output yaml file after that generate.

B

Fibonacci namespace and also deployment.

B

This is very simple design uh for demo in actual design pattern you can add liveness and readiness, proof or adding uh ad animations or specified correlations based on your application requirement.

B

Okay, uh let's move to a second step demo.

B

Okay, uh current manifest does not deploy ingress and service, so we have to update design product to expose api, endpoint and add monitoring functions.

B

Okay, let me show you what to do.

B

Okay, let me uh change my our branch check out to testing okay uh at first generate text on pipeline as same as previous version.

B

And also run it at first, okay, okay, then uh pipeline just checked, and before I uh go to tecton dashboard, let me show you a little bit: what's the new stuff?

B

Okay, this is a brief. You can see the import design, new design pattern, gcp api and added new input parameters to specify the global ip name or domain name, and also this is just binding parameters.

B

And at last, uh at its uptime check, config: okay, then, uh let's go to the tekton dashboard.

B

Racking this is running. Actually, the build image part is totally same with previous one and deploy fibonacci is now just start. It okay.

B

Working okay, just comparing now, as you can see, the uh compile part is totally same. Actually uh revision version is has been updated.

B

Then you can see generated new furniture manifest okay, you can see new deployment, uh new humanities manifests, you can see the ingress part and with the annotation kubernetes ingress and specified global static, ib space right specification and the also the service. First, you can see service resources and other annotations that google cloud network endpoint group.

B

So, as you can see, the new design pattern generate these kind of updates and also you can see, check api task. So this means the new design pattern uh also update the text on task as well and uh create uptime checks, resources and check api availability waiting. The api works. Fine then it looks the this pipeline works works. Fine, then let me check the uh application status.

B

Okay, hello world. uh This means the new design pattern is working. Fine and endpoint works fine and also check the uptime checks. Let me.

B

Reload reloading.

B

Okay, uh you can see cubicle demo, app, actually uh check status is uh have run, have not run yet, but I think this uh takes a few minutes. I think maybe it will be fine.

B

Okay. uh This is uh one with the design protein user scenario. I think uh that's all my uh that's all my demonstration, as I shown uh at the api endpoint and create uptime checks, resources by just change design. Button. Okay, uh as you shown.

B

After it, api endpoint is working. Fine, you can see her work and also the you can check the uptime checks.

B

B

Okay, uh you can see cubicle on them up, then all stators is going. Okay, uh that's all from that's all my demonstration.

A

Right, so thank you for the wonderful demo rintaro. The point was that a user just subscribed the api design pattern and then user can easily expose its applications api to customer.

A

This implies that design pattern could be written from written by a different engineer like the one who is specialized in the google cloud.

A

Google cloud specification because they require some object, uptime check, config and some other load, balancer specifications and user just need can focus on the flask application in this demo. So this means that we can apply this scenario into many other uh cases.

A

For example, we can apply this into the security scenario, uh having a dedicated security team who can just focus on the design pattern for the security and enforce the security policy like having a security check scanning a container renewability check scanning and others.

A

In addition, we can also apply this design pattern to observability.

A

We can have another team who can write a design pattern to establish a monitoring use case, have some agent to collect the metrics telemetries and send it to some back end. For example, we may we can have some design pattern per we're, turning back and like datadog or maybe stackdriver cloudwatch, and so on.

A

And then, and also uh we can use this design pattern to just swap the platform. We just need to prepare design pattern per platform, and if you want to just move your application, you can just you just need to swap the pattern to the other platform.

A

So I think the design pattern has many potential and let me add more about design pattern as code.

A

So design pattern as code is a new interface for maximizing product value stream. It is to write infrastructure as code with a software practice to scale, and also it includes pipeline to architecture. Design and design. Pattern is called the developer, reuse, well, architected patterns and reduce infrastructure management cost.

A

As a result, developer can focus on its application business logic more before.

A

Well, design pattern, as code is one of the implementation of the idea of configuration as data an approach to generate configuration in a pipeline, but design patterns code is unique because it covers pipeline as well.

A

I must leave note that design patterns code doesn't solve every problems around infrastructure's code. Design pattern is a new interface new tool link, but it to use it in the production pro. I we believe that it requires another layer to do the state management.

A

So we entity communications have built a new platform on top of design pattern as code state management, which I described in the previous slide, is already built in this platform, and we also automate all of the operations around using design pattern as code, for example, parameters handling.

A

So our as a results, our platform, let developer easily subscribe patterns and truly focus on their application development.

A

Oh and I I need to mention that this platform is only used for the internal project for now, but if you guys are interested in please reach out to us.

A

At the end, we propose design pattern as code. It is reusable and composable pattern of cloud native architecture. Design patterns code includes both manifest and pipeline and solves consistency and reusability for those pipeline and manifest.

A

Thank you for listening our session and, if you guys have any questions, feel free to reach out to us at twitter. We are happy to have some discussion about infrastructure's code in general as well.

A

A

Okay, so it's live q a session now. uh Thank you for listening. uh Let me pick some of the questions we have here. uh Let me see- maybe this one I'll first publish the answer to public so that you guys know that all the users know the question.

A

So the question is uh about the design pattern. As a code uh is it only for the kubernetes or maybe or it can take care of the other infrastructure and the question the answer is: I can uh take care of the infrastructure like ccp as rinton showed in the demo, though the demo was.

A

There was a huge delay on the demo, so uh but there's a note that here that the our approach is currently only for uh the cloud declarative api and as far as it has a decorative api, it should be able to take care of those infrastructure deployments by deploy design pattern as code, because we can just. We just need to build the decorative api uh using the q, language and composite, and then we can deploy so uh yeah.

A

So the answer is, we can take care of the other infrastructure and the gcp is the one use case. We already showed okay. That was the one question and let me pick another one and hand over to in tarou.

B

Okay, okay, uh let me pick number 12 question. The question is that did you consider consider argo over tectum yeah? uh Actually, I know the argo is great with this application, but at that at this moment the the answer is no, because the argument is the kind of the full design, the application deployment logic I mean the deployment logic is the I mean.

B

Kubernetes kubernetes side has deployment logic, but our approach is that we are leveraged tecton and we can define and we can customize our only our specific uh development logic like taking baby backup or loading upgrade based on the application requirement.

B

That's, I think the difference very different point.

A

B

Okay, thank you.

A

Let me pick another one, because we still have some time here is another question I published to public.

A

So the question is: are the pipelines for deploying and deploying infrared code or for deploying app itself- and this is a great question, because the answer is both uh our approach is to take care of both the generating the infrastructure's code from design pattern and deploy it to the kubernetes. It means deploying the application itself and, as I answered before in the previous question, the design pattern as code can take care of both kubernetes in the other infrastructure layer.

A

A

As a result, our approach it will take care of generating the infrastructure as code for both kubernetes and and the cloud infrastructure layer and deploy the application on the cloud infrastructure, and this is can be so using the q language. We generate the the collective api for both deploying how to deploy the application, how to configure the infrastructure.

A

Okay, so that's the answer and rental. Would you like to go next.

B

uh Okay, let me pick number 39.

A

I think that's the last one.

B

Okay, the question is: does it support telehome project? That's a very good question. Actually we love telephone and we are actually still using telehome, but uh actually in our internal project, uh we are using prumi. The promise I can I mean premier can use we use telehome provider, then the we. The answer is we're still using uh telehome, but we want to migrate to prove me because it's more programmable interface that has more programmable interface.

A

Okay, okay hold on so I think it's time to finish this session and thank you for joining the session and feel free to jump into the slack channel that we will still online to answer the remaining questions. Thank you.

B

Thank you, bye.