Skip to main content

DevOps Decrypted

Charlotte Hester
Charlotte Hester
24 March 22
DevOps Decrypted

Summary

In this months episode we discuss DevOps in the cloud looking at people, processes and tools. Our upcoming sessions with BrightTALK - Day to Day DevOps - Modernizing Applications with DevOps and Cloud-Native Enterprise DevOps Summit We share with you our latest whitepaper: DevOps in the cloud: evolving your tools, processes, and culture.

Transcript

Romy Greenfield:
Hello everyone. And welcome to DevOps Decrypted. This is our episode number nine. Cloudy with a Chance of DevOps. I'm your host, Romy Greenfield.

Romy Greenfield:
And joining me today. We have Jobin and we have a new speaker Peter Daugavietis with us, who is the principal DevOps architect at Adaptavist.

Jobin Kuruvilla:
Welcome Peter.

Peter Daugavietis:
Hello.

Romy Greenfield:
Welcome. Sorry, I wasn't around for the last episode. I unfortunately finally caught COVID after not managing to get it for however many years. But sadly, Matt will now no longer be joining us because he's decided to leave Adaptavist, sad face, but we have Peter now. So, out with the old in with the new!

Peter Daugavietis:
I hope to be able to fill the shoes to at least half.

Romy Greenfield:
I'm sure you will. And I'm sorry, Matt, if you're listening, we didn't mean it to sound so rude. We miss you.

Jobin Kuruvilla:
I'm pretty sure we are going to get back Matt as a guest probably. And telling us about how wonderful he's doing in his new adventure and...

Peter Daugavietis:
Absolutely.

Jobin Kuruvilla:
Brag about it, I guess.

Romy Greenfield:
Yeah, definitely. Yeah, it'll be fun to have him back as a guest. So on today's episode, we are going to be doing some BrightTALKs and I know Jobin you're going to be doing the BrightTALKs. So do you want to tell us a little bit about that?

Jobin Kuruvilla:
Oh, absolutely. Yeah. This is going to be a talk on modernizing applications with DevOps. We'll be doing this as part of the Day-To-Day DevOps with Helen Beal. I think there's going to be representation from GitLab, Digital.ai and myself Adaptavist. It's more like a panel discussion on modernizing applications with DevOps. There's going to be a lot of things around it, but Peter, now that you're here, what comes to your mind when you talk about modernizing applications with DevOps? Just one thing. I mean, obviously we don't want to have a panel discussion here about that.

Peter Daugavietis:
Yeah. I mean, in a word, I would say architecture and leading on from that as an approach.

Jobin Kuruvilla:
It all comes back to containerization isn't it?

Peter Daugavietis:
I think pretty much everything tends to, yeah. I mean, you get all those benefits and yeah, I promise not to talk too long about this, but with containerization, you get the benefits of isolation, encapsulation, all those things that are good for portability and resilience. And I can run my app wherever I want in the same way, it's very expected results. And that's very different from what's been historically available within on-prem data centers and within more legacy software approaches. So if anything, modernization would be that, another word would probably be monitoring.

Jobin Kuruvilla:
Agreed. I was actually taking notes so I can speak about the exact same thing on the BrightTALK.

Peter Daugavietis:
There you go.

Jobin Kuruvilla:
All right. But that's not just about it, right?. I was actually going through a white paper that's coming out soon regarding DevOps in the cloud, and you're a primary contributor on that. So should we talk about it?

Peter Daugavietis:
Sure, sure. Yeah, we've done a white paper to talk about cloud and cloud migrations and eventually then DevOps in the cloud. And it's the big differences that are between on-premise data centers and in the cloud, and specifically also not the combination, but the distinction between cloud hosted and cloud native. And it's very along the same lines where the word DevOps means a lot of different things to different people. To me, it's very much a culture based thing. It's a set of beliefs and that kind of thing that allow you to get to a much more resilient, functional, higher functioning, and eventually better quality application system for your clients or for your customers. Moving to the cloud enables you to do a lot of things much more easily because everything effectively turns into software defined.

Peter Daugavietis:
So now if I need a new machine, if I need new capacity, if I need more, anything, I can very, very easily, very quickly write a little script, stand up some new compute resources and boom, "I'm now running at a much higher capacity than I was". Whereas in the old data centers, I would have to provision hardware, I'd have to ship hardware. I'd have to now bring it into the data centers. I'd have to worry about all the power requirements and in a more a cloud based approach, you don't have to worry about a lot of those things in terms of the shared responsibility model.

Jobin Kuruvilla:
Yeah. There's a lot of things that you mentioned. So we need to break it down.

Peter Daugavietis:
Yeah.

Jobin Kuruvilla:
It's funny when you mentioned about cloud hosted versus cloud native, right?. That's something that a lot of people don't grasp. For example, we were talking about running monoliths in cloud just in the last episode. So obviously cloud hosted means you can take a monolith exactly as it is in on-prem and put it in a container or maybe on an EC2 instance in cloud and it becomes cloud hoster, right?. But that's not necessarily cloud native.

Peter Daugavietis:
No, it's a relatively fine distinction, but it's a very, very important one. At the end of the day, cloud is just somebody else's computer if you think about it that way. So I can take whatever I want, whatever application I might have and I can stick it onto a machine that I got from AWS, whether that's an EC2 instance, or maybe I got an Azure machine from Azure or a GCP machine from Google. And now my application is now in the cloud, woohoo!

Jobin Kuruvilla:
Yeah.

Peter Daugavietis:
So I get all those benefits and it's a great thing to be sure. But when you start talking about cloud native, cloud native really becomes more of a set of architectural decisions, architectural guidelines, application design guidelines for maximum resiliency, uptime, disaster recovery potential, all those things. Sorry, go ahead.

Jobin Kuruvilla:
It is a good time to bring up the six Rs of cloud migration because when you say cloud hosted, we are probably talking about a rehost, which is the first R, then you have re-platform, repurchase, refactor, retain and retire. So what you're talking about is more like re-platforming and refactoring, right?

Peter Daugavietis:
Absolutely. Yeah. Yeah. To do a cloud migration, you'd be following the Rs. If you're doing maybe a brand new application, you'd look towards things like 12 factor apps or those kind of things where you start building them with things like messaging or a degree of asynchronous behavior to better mimic or better get your application design across and again you get into differences of, do I refactor?, do I greenfield?, whether or not scope, scale, everything else lets you go one way or the other, but you still want to take into account the underlying capabilities of cloud such as really easy auto scaling, software defined pretty much everything. And you're no longer limited by, oh, it's going to take me six weeks to get a database from the database team or to stand up a new Oracle instance or to stand up a new Hadoop cluster or something like that because I need 200 nodes to run my data lake.

Peter Daugavietis:
Well, I can now do that rather. I'm just learning how to speak now this week, so.

Romy Greenfield:
I only speak computer.

Peter Daugavietis:
I speak like this usually. You have the ability because everything's software defined to stand up and tear down things very, very easily, very, very quickly, which also then begets into an R&D mentality where I can try something out. I can see if it works. I can throw it away with very little cost incurred in terms of effort and in terms of actual tangible cost and tangible assets. But I'm also now enabling my development teams to operate that much faster. And again now you can start to talk about time to market, again delivering the value stream that much faster, those kind of things, and providing the business value to your end customers much, much quicker and much more better to use a very underwhelming word.

Jobin Kuruvilla:
Yeah. I think for me, I mean, when you're talking about DevOps and cloud, there are these basic pillars which we talk about, right?. Scalability which you mentioned about, then there is high availability, disaster recovery, lot of those core things that you would be looking for when you're re-architecting your application, that's there, but you also mentioned about the flexibility with environments, right?

Peter Daugavietis:
Yeah.

Jobin Kuruvilla:
So, that could mean a lot of things. Romy, you would probably appreciate it since you're from the product team to spin up environments faster, because I think you go back 10 years back to get a new test environment. It probably took weeks if not months, right? But now to spin up an environment in AWS, it just takes us, I don't know, a few minutes, right? Especially when we have our own AWS that comes like Adaptavist gives us, it's even more easier. So, that's definitely there, spinning of environments faster. Then, there are parallel environments for testing because earlier you had 10 developers working in a single test environment, somebody breaks the environment, everybody else goes for coffee or tea because you can't work on the environment because it is down, right?

Peter Daugavietis:
Yeah.

Jobin Kuruvilla:
Now everybody gets there on environment, which means parallel development. I think Peter, you also touched on ephemeral environments right?, just bring up environments as we need it.

Peter Daugavietis:
Yep. And one of the biggest things of all of this, like we've thrown around the word environment so much, one of the biggest parts of this is that environment can have the potential to be a mirror of what's in production. So that's a huge one where you traditionally have had development environments, test environments that are shades and shadows of what production, grades, size, configuration, all those things are. If and when you need to, you can have non-production stacks with the identical configurations, identical sizing, identical everything attached to them in production or non-production. And that begets the idea of what Jobin just mentioned ephemeral environments, where the environment itself now becomes just an environment. And now you can hang whatever label you feel like using on it.

Peter Daugavietis:
So today it's a dev environment, but now you can promote that entire environment to dev, to test, to load, to production. And instead of now, just the artifact being a JAR file or a NPM or whatever you could actually promote entire environments...

Jobin Kuruvilla:
It is sort of...

Peter Daugavietis:
From one level to another like it's kind of getting your cake and eating it too in a way.

Romy Greenfield:
And I love cake.

Jobin Kuruvilla:
It is sort of like...

Peter Daugavietis:
Cake is always good.

Romy Greenfield:
No cake.

Jobin Kuruvilla:
It is sort of like blue/green environments when you think about it, right? Whatever color you want to put on it? You have similar environments all the way through to production. So, yeah, you take a staging environment, today is staging, tomorrow it becomes your production, right?

Romy Greenfield:
Yeah.

Jobin Kuruvilla:
And that helps with, I don't know, zero downtime deployments. You just want to point maybe your application load balance into the new environment and boom, there it goes right? Maybe with technologies like Kubernetes you're probably talking about canary deployments and stuff, but anyway, whatever it is, right? You have similar environments lying all over all the way to your test environment. Maybe even your developer environment because you are spinning up using the same core that you're using to spin up the production environment, right?

Peter Daugavietis:
Yep. Yeah. No, it's very much... And I think I'll be the first to then coin it. We're going to call these Adaptavist rainbow environments because really they're blue, green, orange, purple, red, whatever color of the rainbow we want to use to represent whatever stage of the process we're in.

Jobin Kuruvilla:
Exactly.

Peter Daugavietis:
But that's really the punchline is that it moving to the cloud is the first step of that journey of embracing the cloud, which eventually will get you to being more cloud native in thought process implementation and all those kind of things. And that's really what I really enjoy doing for a lot of our clients is kind of opening their eyes a little bit in some ways to say, like being on AWS is cool because that's where all the cool kids are and it's a nice buzzword to have, and those kind of things, but the actual power that comes with that and the ability that you can incur or infer and then empower everybody with is it's pretty cool.

Jobin Kuruvilla:
Yeah. And if you take a step back, right? I mean, what we are saying is DevOps was always good. DevOps came up with a lot of practices, obviously it took a cultural sense and we are talking about CI and CD and creating appropriate branching strategies, creating appropriate environment strategies, release strategies, right? That was all good. But once it got married to cloud, it became even more easier. Now you have the technology to make it even faster, right?

Romy Greenfield:
Yeah.

Jobin Kuruvilla:
As I said, spinning up environments as needed all those kind of things, it becomes so much more easier. So DevOps and cloud is actually one more step ahead where everything is easier, right?

Peter Daugavietis:
Yeah. DevOps supercharged.

Romy Greenfield:
DevOps squared.

Jobin Kuruvilla:
Yeah. And cloud also comes with certain other advantages, right? I mean, there is like centralized governance that you can do on it. So it's not just anybody can create anything that you want. You can also set up certain practice or certain standard governance around it. So that you are creating only what you are allowed to do even if it is on cloud, right? So there is actually security as well, right? Governance and security, right?

Romy Greenfield:
Yeah. I mean, we use that a lot when we have support engineers where they might need to read information so that they can understand whether something's going wrong and highlight it to us, or if that's not the issue. So, giving them access to certain pieces of infrastructure that's available in the cloud to allow them to make our lives easier and their lives easier because they know what's going on rather than having to wait for a developer to actually go and investigate it. But we found that really handy on our team. It's definitely improving like the speed of response that people are getting in support and obviously no risk of them deleting something business critical by accident.

Peter Daugavietis:
Yeah. And that's the one thing that I think in a lot of journeys, identity and access management sometimes becomes a little bit of an overlooked aspect of things. And again, in the cloud, what you can do with, let's say an application load balancer is, I can by code automatically wrap that in an authentication request against an active directory database, let's say, so that as developers you no longer have to worry about or have them worry about a lot of the implementing fine-grained permissions and access and everything else.

Peter Daugavietis:
We can actually delegate that to a different layer of the application and delegate that actually to the platform that it's running on. So that's where you get into again being more cloud native, you can embrace the underlying platforms, whether that's public cloud or private cloud. And that's another distinction to have is when we talk about public and private clouds, we're talking about AWS, Azure, GCP, those kind of things in public cloud, but all of this cloudish behavior and everything else equally applies to private clouds like either pivotal cloud foundry or any of the cloud foundry family, or things like OpenShift and the Kubernetes at its base, Kubernetes being the open source version of backing that powers things like elastic container service EKS on Amazon, Azure containers on Azure and GCP, a Google container platform.

Jobin Kuruvilla:
It's interesting that you brought it up because I'm torn between being cloud native versus cloud diagnostic, right? I mean, obviously you can be as much cloud native as you want, but then you're probably married to certain vendors, right? I love AWS, we are an AWS partner, but at the same time, do you want to be using things like EKS or would you be rather using Kubernetes and running it on EKS or GCP wherever you like as opposed to being married to one particular vendor?

Peter Daugavietis:
And that's part of the argument of why, again, everything rolls back to containers. So long as you've containerized an application in a way that makes it portable, I no longer care as an application developer specifically where my application is running. I don't care necessarily as a product owner where my application is running. I can defer that to the platform teams. And if the platform team chooses AWS, that's fine. If they choose Azure, that's fine, GCP that's fine. All I care about is the ability to run my application and get a URL somewhere, right?

Jobin Kuruvilla:
That is absolutely right. But when you think about, let's say, creating the infrastructure, right? I mean, there are so many different ways to spin up infrastructure on AWS. You can be using Ansible, Terraform, but you can also be using CDK. I mean, I know you are a big fan of CDK, right? But once you're using CDK, then obviously you're married to that technology. If you want to go to Azure, you can't use CDK.

Peter Daugavietis:
And again that becomes part of the choice of where you end up going. And again it becomes more of a business choice. And you have the ability to run Kubernetes for instance as your base level baseline, but you could actually have your worker nodes maybe spread out across multiple cloud hosts. So that's another thing that, again, it gives you that abstraction layer that I can have, for instance, I know the one place that was running an OpenShift Kubernetes cluster, but they happened to be running some of the worker nodes on AWS, some of the worker nodes on Azure, some of the worker nodes on GCP. They ran a mixture of Linux and Windows hosts.

Peter Daugavietis:
So now you can host both Windows workloads and Linux workloads, but they're all appearing through a common control plane, a common interface using common deployment manifests, those kind of things. So again, as with all things in IT that I'm sure we're all well aware of, there's trade offs. So you get six of these, but you have to pay seven of those, or you get half a dozen of these and you get half a dozen of those. And with infinite choice comes infinite complexity.

Jobin Kuruvilla:
It does. So being cloud agnostic is not always safe is what we are saying.

Peter Daugavietis:
Or easy.

Jobin Kuruvilla:
Or easy. Absolutely. Yeah.

Romy Greenfield:
Definitely not easy.

Peter Daugavietis:
Yeah. Yeah. A lot of the time it's also good like everyone's got to start somewhere. So, back to the Agile principle of minimal viable product. Okay. So for the first run, we're going to do AWS and EKS and get our application running. Now that our application is running. Now we can look back and say, okay, actually, you know what, maybe we do want to make sure that we're on AWS and Azure. Well, our DevOps, the platform team guys can take a look at this.

Peter Daugavietis:
And because we're running Kubernetes, because we've got a containerized application, the effort to go from one to the other or across both is much, much simpler than it is if to say that I had a more legacy application that had 26 different components, but they're all extremely tightly coupled, they all need direct network access to each other, something again as opposed to be having HTTP links between them and stuff. Then, you get back into the whole application design portion of this, but that's also part of that whole "moving to cloud is one thing, but being cloud native is another".

Jobin Kuruvilla:
Yeah. Because, I mean, it's very, very easy...

Peter Daugavietis:
There're so many choices... Sorry, go ahead.

Jobin Kuruvilla:
Sorry to interrupt. I was just going to say that it's very, very easy when you're talking about Kubernetes, right. We know that it can be ported anywhere, but when you're married to technology like Lambda, for example, being a cloud native technology, it's not going to be that easy because once you have made that decision, and once you started working on it for maybe a year, maybe two years, you are married to the technology now. There is no equivalent alternative on the other cloud platforms.

Jobin Kuruvilla:
So when you are in that re-architecting, re-platforming phase, you might have to think about, okay, what am I going to need in two years' time, five years' time. I mean, am I looking at creating an application that's cloud agnostic? I mean, is that one of my priorities or is it just going to be doing it faster to take all the advantages of the cloud native services offered by certain cloud providers? Lambda is a good example, right? So I think making the decision early on will help you in the long run, don't you think?

Peter Daugavietis:
Oh, absolutely. Absolutely. Well, and as with everything is, architectural principles are those kind of much more broad concerns of do I go this way or that way? But it's also then making sure that we're all understanding the impacts of going one way or the other, because every decision has consequences. If I pick chocolate, I can't have strawberry, but occasionally there're times when you come to Adaptavist and we'll help you get neapolitan and you can have all three.

Romy Greenfield:
That's the thing, you can have all three, but you've only got a limited supply of each.

Peter Daugavietis:
Exactly again, trade offs. Right?

Romy Greenfield:
Yeah.

Peter Daugavietis:
And I think we talked about that earlier as well, is that, with everything, every decision has consequences, every decision has trade offs and it's up to us as myself as a principal solutions architect or consultant or I'm not even sure what I'm supposed to be called anymore. It's up to us as system architects, as system analysts to look at the system as a whole and make those decisions and try to guide into best practices, follow things like Jobin mentioned the pillars of let's say the AWS as well architected framework. So making sure that best practices and good principles and a good foundation is laid so that even if you end up in two, three years wanting to go down a refactor path or a re-platform path, making sure that you haven't necessarily shot yourself in the foot with decisions and choices that were made prior and try to limit the impact, limit the scope, limit the blast radius, depending on how you want to look at it. But...

Jobin Kuruvilla:
Yeah. Sounds good. Since you're talking about DevOps in the cloud, I mean, I think we should be talking about the various DevOps tools offered by the cloud provider software. You talk about AWS, for example, there's AWS CodeBuild, CodeDeploy, CodePipeline. We have various things offered by Azure, I'm sure Azure DevOps, there are a lot of other tools out there which support different cloud providers like GitLab, for example, it supports all the different cloud providers. So, that's an interesting choice too, right? I mean, when you want to do DevOps and when you want to do DevOps in the cloud, what tool should I be sourcing? I mean, does one tool have advantage over the other one?

Peter Daugavietis:
I would say that, yeah, every tool has something over the other one. AWS does have a bunch of code related things built into it. Obviously, they're going to be opinionated to AWS services. So they're going to be a little bit more tightly coupled that kind of thing. But if you look at something like a GitLab is something that would sit on top of and be a little bit more cloud agnostic, but then give you that abstraction layer to give, and in GitLab's case, a very wide range of functionality and really excellent set of SDLC related concerns, but not tie you down too much in terms of, oh, well, if you come into AWS, well, now you're stuck here. Or if you go into Azure DevOps, oh yeah, now you're stuck here. It gives you that layer of abstraction on top of a lot of different technology choices.

Peter Daugavietis:
And I think that's the bigger part of that whole discussion too, where you want to try to stay as generalized as possible and possible is going to be the trick. But don't paint yourself into a corner. Don't pick a web framework library that was written by uncle Bob at the back of The Falafel Shack as opposed to something like Spring Boot or a larger, more well known framework, because you know that the larger one is probably going to be around for more than six months, as opposed to, oops, I included a library that's now out of date and has been unsupported for the past 15 years.

Jobin Kuruvilla:
That is valid advice for all tools, for any technology that you're going to use. But at the same time, I would say that there could be perfectly valid use case where you want to pick a tool over the other. I mean, it could be because you're already...

Peter Daugavietis:
Absolutely.

Jobin Kuruvilla:
Yeah. You're already in the cloud, you know that you're going to continue in that path and you want to take advantages of its tight integration with the other services offered by the same cloud provider, right? And that is also why there is no one DevOps solution that fits for everyone, right? For each customer, we have to look at the special use case, identify what tools, what process best fit for that particular customer. And that is also why we hire people like Peter to come and take a look at the system. And definitely, I don't mean it as a sales pitch for Adaptavist I'm hiring Peter but...