Cloud Native Computing Foundation Serverless Practitioners Summit 2019 (San Diego), 24 Nov 2019

Previous Meeting

⏯

youtube image

►

From YouTube: Working with Serverless Functions and CI/CD - Avni Patel, CloudreachSDCC

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Working with Serverless Functions and CI/CD - Avni Patel, CloudreachSDCC

While working with serverless functions in CI/CD, it is key to develop structure. When do you add all your serverless functions to a single code base, when do you branch it out, and how do you maintain code quality and consistency? This will include key strengths and weaknesses from different CI/CD structures and lessons learned from different approaches.

A

Okay, so I'm nipa tell I'm a cloud software engineer at cloud reach and we're a consulting company that basically helps enterprises get to the cloud or build their applications in the cloud and I'm talking about working with several is functions in C ICD and mostly I'm, trying to focus on the developer point of view. So a lot of you guys are talking about running serverless workloads, but this is more about running them on AWS or GCP or asher.

A

Okay. So as a developer, you basically you're using something like serverless framework or terraform to build out your application. And when you do this, you build out use your framework to build out a bunch of functions and a bunch of infrastructure.

A

There's probably should be like more infrastructure down there and then your functions will use the infrastructure, whether that's using them like an event trigger so they're calling they're using some they're using something to like as an infrastructure, resource or they're using some kind of library. To like. Let's say you have DynamoDB and you're pushing to a table or something like that so yeah and then as a developer.

A

So you're not just writing your code anymore.

A

Yeah so you're not just writing your code anymore. You're! Writing your code. Hopefully you're writing a bunch of tests, so you have unit tests, integration tests, load tests, depending on like how many tests, you're, writing and then you're also building out your infrastructure, and then you have infrastructure tests.

A

So hopefully you have all those tests, but I mean maybe you don't and then, when you're working with a pipeline, what you're doing is you're pushing your code and you're trying to build out all of the tests and making sure everything builds and then, when you do this, the time to actually deploy your code takes a while right. So, for example, if your your infrastructure code is like building g ke g ke takes like 20 minutes to build out a cluster, and then you have to wait for that.

A

Every single time you push or and then like some of your components, don't take as long, but there are components that take awhile so yeah. So your your continuous integration process is slowed down as a developer, as you have to wait for your pipeline to build and then so. How do you like? How do you deal with that like? How do you deal with all of those components and building them out, and then how do you deal with code promotion to different environments?

A

That kind of speaks for itself so, basically, like you, want to make sure all your infrastructure components work with your code and then you have a whole bunch of code that depends on infrastructure directly. So you want to make sure that you're testing every single part right.

A

But then, when you actually are developing so like, let's say your like, your service framework is only using s3 bucket or something like that, and you only create the bucket once and you never have to recreate the bucket. So most of the time, you're only pushing your code and you only have to worry about those tests right. So why are you building out every single other component and checking it right?

A

And so the first thing you can do is D couple your code from your infrastructure as much as possible, and then I actually saw the second thing in the Cerberus framework.

A

Best practices is that if you have two different functions that are actually using the same component, then just take that infrastructure component out of your like lambda function and then just put it inside of a separate repo and just have that run on its own and then so. Integration test can be your best friend. So, for example, I was working on an application and we were using.

A

We had see our and then we had dynamodb, and so we made a change when and someone had a micro service that they changed the version to so the endpoint changed. And then, when we were running our dynamo deep and when we were running our lambda functions, it wouldn't. The integration test went up fast because the endpoint changed. So it's a good way to make sure that all of your components are working together without having to make sure that your entire pipeline runs every single time and then so.

A

You should still be running you're into your infrastructure pipeline every single time, but your developers shouldn't have to wait every single time. You run right. So you want to break up your code pipeline from your infrastructure pipeline, but still have the code pipeline trigger your infrastructure pipeline and then so. The different components, don't matter as much so I mean it doesn't have to be like your.

A

Your code pipeline is just running, build test integration test and then like you're, not doing a terraform plan and apply, but you should have different pipelines so you're not waiting as long and then so. There's like different patterns for your server list code, so for different patterns.

A

You want to do different things so for the microservice pattern in the service pattern, you want to have different pipelines per micro service and per service, so this helps with continuous integration, so you're only making sure that your service is building and passing every time and then the integration every single function should be able to trigger the integration and then for the monolith pattern.

A

You basically want to run all of your tests because, since all of your code is highly coupled, you want to make sure that everything works all the time and that should also be able to trigger infrastructure by play.

A

Ok, so then, another problem that we've run to run into is that the developers, even though they would push it, would just take forever to have everything build out and they weren't testing their code locally. So they'd have that huge pipeline and then they would mess up at some point and then they would just have to start over and like one of the pipelines we had was like 50 minutes long, so they wait until the last component just for everything to fail.

A

So one thing you want to do is you want to make sure that you're you're having your test run locally first, so you can create like a doctor vial that has like all of the tests and just run that or like we were. We had pre-commit hook, so you couldn't punish unless everything was passed or like some certain things were passing and then we're like running a script.

A

That just has everything that you need and then also just make sure your integration tests are like really really well put together and then, when you actually do promote your code, you want to make sure that the entire pipeline actually does pass, because you don't want to make anything fail at that point. So, like let's say, you're pushing to dev, you want to make sure everything runs you don't want to like. You want to make sure your merge request passes every single component. You don't want someone to push the dev and ruin a different function.

A

Things like that, okay and then so for every single pattern. You want to have a different type, also right so for micro services and services.

A

So the when you, when you promote your code, you should run your micro services pipeline and then push to the infrastructure and then in every environment you should be making sure that everything passes for that and then obviously so you'd be pushing features. You want to be pushing your entire, like all of your changes, you'd be pushing, so you so for every feature.

A

Every feature should be inside of a separate function and then so, if it's okay, so let's say you have a micro service architecture and then all of your micro services are under different folders. So what you would be doing is that you would push those features for that poll folder that learn would trigger its own pipeline and then that would trigger your infrastructure pipeline and then, if you're doing that and like dev, then that would then make sure that everything in Deb is running correctly.

A

Okay, yeah: that's all.