Transcript
0:09
Welcome to Cloud Unplugged, the podcast where we take a lighthearted and honest look at the who, what, when, where, why, how and OMGs of cloud computing. In today’s episode, cloud native, what does it mean to be cloud native? And how can knowing the answer to that question to help you in your cloud journey?
Hi, I’m Joel Parks.
0:27
I’m Jon Shanks.
0:29
And Jon, how was your weekend? For me, it was Memorial Day weekend in the US. And it was a bit strange to be honest.
0:37
Alright, strange how?
0:39
So, typically my sense memory of Memorial Day weekend in the States, year after year has been it’s the weekend where you go stand outside sweat like crazy and grill things. Right? So it’s just hamburgers, sausages, whatever, on the grill. This past weekend was really strange in that at noon, on Saturday, it was only about 55 Fahrenheit, which is about I guess, 12 and a half C right? And sort of drizzling rain and it stayed cold pretty much all weekend. It was really weird.
1:15
So basically, the UK.
1:19
Yeah, but for the, you know, southern part of the United States it was freezing. My brother and father-in-law and I were standing on their back porch sort of trying to finish up lunch and grilling a few things. And we’re like, do we want to eat outside? We kind of looked at each other went, no. We want to go inside.
Yeah, we’ve been lucky actually because it’s been I mean, now the sun’s out. So there’s Bank Holiday and I mean, it’s rained constantly almost the entirety of May. And likethis weekend, which is also bank holiday weekend that we’ve just had was really sunny. So it’s like everything’s come into life. I think it’s about 20 degrees. 24 I think it is today, obviously. I’m lucky because I’ve got the day off. So you know.
You have our weather, we traded!
2:11
We’ve basically swapped, yeah, this is what happens now. This is the power of the podcast, Joel!
2:18
We literally unplugged the clouds, moved them to different places. Oh boy. All right, well, straight on to the news.
So today’s news is really one article. And I thought it was appropriate, because it speaks to something we talked about last episode, but it also tees up nicely, something we’re talking about in today’s episode. So it’s a press release out of Amazon, talking about the general availability of Amazon ECS anywhere. So just for context, ECS is the elastic Container Service. It’s not Kubernetes based, but it’s Amazon’s specific implementation or opinionated orchestration tool for running containerised applications. It’s been around quite a long time, actually. And what they’ve done is they’ve rebranded a portion of it ECS Anywhere. Effectively, what that means is that you can run your containerised applications on, according to the article, on any customer managed infrastructure in addition to all AWS regions, local zones, hybrid infrastructure deployments (meaning outposts and wavelength). And there’s no upfront fees or commitments to use ECS Anywhere, basically, they are now enabling hybrid cloud operation native hybrid cloud operation for ECS. So it’s sort of exactly what we were talking about last time in taking the cloud services and bringing them into your private data centre if you have to, rather than going the other way round.
4:00
Yeah, that’s great. I think they started with EKS-D, wasn’t it – which is distributed, or ECS-D, was it, or EKS-D? They’re separate actually thinking about it now, aren’t they. This is ECS Anywhere. And then there’s EKS Distributed, of which I think they’re also going to do an anywhere as well, I believe?
4:22
Yeah. So I would have to look at it. But based on memory, I believe EKS is available on Outposts. So if you have Outposts hardware in your private data centre, the the list of supported services EKS is on there. It looks like ECS is also now on there through ECS Anywhere. So you can have that you can run EC2, you can have S3 storage buckets run on the outpost hardware. So there’s a there’s a short list of services that are supported. That list is growing now.
4:54
So basically yeah, it’s exactly what we’re talking about, wasn’t it where they’re kind of entering into the markets, on premise markets, in different ways. So one is like go and buy the kit, which is Outpost, but then if you’ve also got kit, then there’s ECS Anywhere now and then there’s EKS Distributed and and I think there’s gonna be EKS Anywhere at some point. And so I think they’re, they’re now kind of bridging into the into the on premise market, somehow.
5:21
Yeah. Which is, which is great. So the other thing that it tees us up for so that’s what we talked about last time. What we’re talking about today is cloud native and containerization, or running and building containerized applications, is really key to the definition of what it means to be cloud native. So from there, Jon, let me just ask you a question. What is cloud native?
5:46
Oh, wow, loaded loaded question. So it depends depends on the definition, I guess. So if you look at cloud native definition as in the CNCF itself, then it’s a way to run and build applications in kind of modern and dynamic environments. So that’s pretty much anywhere public, private, and hybrid. And is a selection of different technologies, obviously, service meshes or like observability technologies. But fundamentally, the premise is around containers to begin with. And it’s kind of morphed into a more generic set of technologies, including serverless.
6:25
So I sort of teased this topic a little bit last time. And it was in the context of the O’Reilly book that recently came out. Now the way that they go about defining cloud native is through five primary categories. It’s containerization, dynamic management, microservices, which is really speaking to the the software artefact or the software object that you’re creating automation and orchestration. Sounds like the CNCF has a fairly similar definition, but maybe they’re taking it in some different directions, or including things that maybe the O’Reilly book isn’t. Am I understanding that right?
7:02
Yeah, I think so. So I think I think they, well, one’s probably more of a natural progression where technologies have entered the space. And then they’ve worked out themes for the technology. So maybe it’s been more technology driven. And so then they’ve kind of bucketed things up in like app Dev, or orchestration and management or runtime and provisioning. But obviously, there’s natural overlap, because that’s kind of what the book, O’Reilly book’s, kind of touching on. Although is, from what I can see missing observability you know, which is a bit strange.
7:32
Yeah, that’s kind of a big ommission, because and to be fair, I have not read that book comprehensively. So maybe it is tucked away in there somewhere. But I, if it’s not in there, or if it hasn’t been set already observability, making sure that you can understand how your systems and services are behaving, is absolutely critical in cloud and really, in any environment, to be honest, otherwise, all the methods and processes that we’re talking about are gonna let you move very, very fast. But it’s a little bit like building a Ferrari with a solid front windscreen, it’s gonna let you drive very, very fast directly into something. So you know, please, please avoid needing a crash helmet.
8:17
Yeah, and I think looking at the two as a comparative, one is, like they’re both five things: app dev, orchestration management, runtime provisioning, observability and analysis. And then from the book, it’s containerization, dynamic management, microservices, automation, orchestration. So I think it’s just like a repurposing, but more on a principle set, because obviously you’ve got microservices in there. Whereas that isn’t, the principles aren’t, I guess said fall into App Dev. But it’s more of a technology grouping rather than maybe a set of principles…
8:49
Yeah, my my takeaway from this is it looks like the the CNCF description is probably more tailored to enterprise or business consumption of these ideas and implementation thereof. Right. So I think one’s and maybe a bit more academic description of the concepts. You know, the CNCF definition is a bit more concrete. And it’s it’s also slight, maybe one degree more opinionated, which in this case, I don’t think is a bad thing. Because it’s such a wide world, that, you know, those those opinions are actually pretty helpful, especially if you’re you’re getting started. So I would, I would say, you know, maybe let’s take the CNCF definition and use that to contain this discussion about, you know, what it is to be cloud native, you know. What does that practically mean for, for our teams? So, what do you think about, Jon?
9:48
I think that makes a lot of sense. I think I think the book’s probably getting into software development principles. I imagine there could be a writing one which we can kind of cover in a separate app. So to believe we’re probably going to… not to tease it up too early.
10:03
Jon, you’ve taken the trophy back. That’s all I’m saying. You are now you remain king of segways! So we’ll we’ll talk about that the end of the episode. But that’s exactly where we’re going next time.
10:18
Yeah. So I guess this one, this is more just to cover, like what cloud native really is? What it means to be cloud-native.
10:25
Yeah, in practical terms, if you’re getting started with cloud, we’ve talked about a lot of ways to get you moving, to get you steered towards cloud, giving you some ammunition to deal with conversations that are likely to come up within your organisation, things that you’re going to have to sort of clarify both for yourself and also for your team.
I think the the ‘what is cloud native’ question is a pretty big one. And it’s likely to come up at some point or another, you know, in the context of trying to figure out, are we building things the right way, primarily. The term cloud native has been around for a long time. But the definition does vary slightly and it has varied over time. I think the Cloud Native Foundation, the CNCF, definition is probably the best because it’s quite broad. But when you get into the specifics of each category, it does become quite specific. So they they provide a big umbrella to define, broadly, what is cloud native, but if you look at each of the buckets, each of the different categories, then there’s not only process recommendations, but there’s tooling recommendations, you can really clearly see the intent behind each of the categories and how they’re meant to apply to, you know, your typical or average organisation moving to cloud.
11:50
Yeah, and I think what’s really important, based on our previous conversations, is factoring this in in terms of the portability. So you know, this vendor lock in kind of fear that a lot of companies have. Certain technologies are not owned by a specific network. Actually, to be fair, a lot of the technologies, a lot of times are not owned by the vendor, but on occasions, like lambda is a prime example of a very vendor specific piece of technology. Whereas this is all about running things in in a way that that is cloud orientated, like elasticity and scale, decoupling microservices, it’s the principles of being cloud-like, but on premise or hybrid, or in cloud in a specific vendored one, which is quite important if you’re thinking then about your approach to cloud. Trying to factor cloud native as a principal in the business, as well as then getting to cloud is probably equally as important. What are your thoughts?
12:49
Yeah, absolutely. I mean, there’s, you know, there’s the the specific thing, then there’s, you know, how it applies to you. There’s a lot of things that, you know, you have to work through, and yeah, the CNCF is a pretty broad community, it’s a big umbrella under which a lot of, frankly, industry focused development is all coming together. And while it’s vendor agnostic, you know, a lot of the work is coming from different vendors, or at least supported in some form by other vendors. So it’s not as if, you know, there isn’t vendor perspective in some of the tooling that the CNCF supports. There is
13:28
Do I detect a little bit of cynicism here, Joel?
13:32
No, I actually think it’s good. I think the CNCF is performing a really good role, because if you go back in the open source world, I think that rallying point, that place where, you know, it’s by design, there’s there’s supposed to be a little bit of friction, and a little bit of contested opinion, you know, where everybody’s bringing something in and then it’s being looked at, examined and refined by a much broader group with maybe not entirely aligned opinions, I think that’s really, really good. Because if you rewind maybe 20 years, to how open source worked, it was primarily very academic, what didn’t have a big community that had those rally points or the organisation behind it to really mature products and move them into a state of usability, broad usability. They were very specific tools created for very specific purposes. And if you knew enough about them, which is the big if, then you could take and adapt them and and implement them on your own.
But let’s face it most, most organisations A) that’s sort of not what they were set up to do in the first place. And B) you know, those projects, in some cases are written by maybe two, three, let’s say 10 people or less. Yeah, so there’s 10 people in the whole world that really know how the thing worked and you know that dynamic’s changed over time. Now you have the CNCF that has, amongst other things, Kubernetes and a bunch of technologies under it, that represent the work of literally 1000s and 1000s of people. And so that is really, really good because you know, the industry or the vendor opinion that may be coming into the CNCF, you know, is getting tempered by the community. So and it’s not to say that the vendors have bad ideas, maybe they have a very opinionated idea, but the community says, ‘ah, that’s really good. But you know, there’s, there’s maybe a quarter of it we don’t agree with.’
15:37
Yeah and there are gated principles of getting things into the CNCF as well isn’t there, it’s governed by a set of rules of which, you know, you as a vendor can’t cherry-pick the things you want to drive as features and then ignore, say what the community wants. So I think I think it’s good in that sense. And, and you’re right as in well, we could probably have a whole other episode on like, open-source business models and open source in general, and all these other things that kind of drive around the open-source really, that people don’t necessarily talk directly about. They just talk about the tech. But that’s a whole other conversation. But I think you’re right in the sense of now, compared to before, now things are a lot more polished, not necessarily like a normal vendored product to the same degree, but still a lot more polished than it used to be where you’re tearing your hair out and go through the code line by line and then adding your own hacks to get something working. Which is how it used to be so yeah.
16:34
Yeah, absolutely. So if we think about the categories that the CNCF defines, right, the first one is application development. Now, this is a pretty broad category. And what they’re talking about here is, you know, the application building blocks that you would leverage to build a cloud-native application. Now there is a famous or I might say, infamous diagram, that the CNCF maintains that’s called the landscape. And the landscape is a very, very busy diagram that follows the five categories that we’re talking about and spells out in, I don’t know what the right word, I don’t know what the right word is here. It’s verbose in picture form. You know, so there are lots of different logos for different projects, and they’ve carved them up into different buckets. And you can get a sense of the different classes of tools. So meaning, you know, here are all the tools that fall into roughly the same compatibility class. For example, within the application development category, the first compatibility class is a database. So this is relatively easy to understand. This is like Maria DB. You know, Cassandra, different database technologies, I think Retis is on there, maybe Couchbase. The second one is streaming and messaging. So this is another concern, or another, you know, type of functionality that you may need to integrate into your application. Here, we’re talking about stuff like Spark or deep stream or Rocket MQ, Rabbit MQ, those kinds of things. And then there’s another category that’s really about how do you build applications. So it’s really about the build process. So here we’re talking about Bitnami. Get pod, you know, lots of different again, this is it’s a very, very busy landscape. And then the last category, again, this is under application development, is CICD. So this is again something that, you know, we will talk about in much greater detail in the next episode. We’ll get to that in a second. But here we’re talking about Jenkins, GitLab, GoCI, that kind of stuff, Travis. But you can see if you pull all of those together, if you have a CI-CD system that’s capable of taking those actions, you have the ability to define and build your container images, we’ll just take an opinion and say it’s containerized most likely, will be streaming and messaging and database. Alright, well, now you kind of have all the components that constitute a three-tier application or something that’s close to it. Jon, what do you think about that?
19:34
Yeah, no, that’s kind of spot on. I think it’s a bit of a challenge to kind of dissect, you know, like the way that they’ve done to dissect the application delivery, the build, the management. But yeah, and obviously, there’s overlap because obviously, building the container without the registry to push it to is doesn’t mean that you can then do anything with it. Well, you can’t get to the deployment phase. I kind of understand the relationships and that and container registries under like provisioning, along with like other things like conflict management, like Chef and Ansible, and things like that, and security. So they’ve kind of tried to work out, like, the app structure itself, like building, managing something in isolation, and then the extra layers that are then needed to like, deploy it, schedule it. Storage for it is then another bucket. And then provisioning, you know, the registries and things of that, then another bucket again. So they’ve kind of put things into buckets haven’t been really to make it simpler to understand the tech landscape of which there is like, nearly 1000 tools, so I can understand the need to make sense of nearly 1000 technologies.
20:44
Right, yeah. And I mean, again, I will, will include a link to the landscape in the podcast notes, and we’ll also tweet it out. But if you look at this, I think what you’ll see is they’ve taken all the concerns both either operational, around building the applications, defining the application’s functionality. For observability, how will you know if the application maybe is malfunctioning, it’s doing something it wasn’t intended to do. And they’ve done a good job of carving up, you know, classes of tools that are, you know, directly comparable. They’re all sort of designed to solve, more or less the same problem, they may go about implementing the functionality in different ways. They may not have specific features that speak to you more than others. But fundamentally, if you think about database, you know, if you think about Maria DB versus Microsoft SQL, Well, okay, they’re both databases, they’re both meant to solve the same problem. They go about it in different ways, but they are comparable.
21:53
So I’m gonna put you on the spot Joel with a question. So if you were to summarise. Well, you don’t necessarily have to summarise maybe give an explanation as to why it’s important for people thinking about going to cloud right now to be considering and understanding what cloud native means. What would you say? Like, why is it important to kind of address and think about cloud native early?
22:21
For two reasons. Number one, it speaks to the thing that we talked about before, of if you’re making the transition to cloud, and you’re being intentional about it, and you’re doing it for the reason that you want to improve your organization’s ability to execute better access to features in the environment or in, in the landscape in the industry, you know, if you want to improve your sort of condition. Then understanding this understanding how the industry views cloud native and how they’re really building services and functions around this definition in this point of view, is really good because it’s a little bit when we talked about the CNCF having 1000s and 1000s of people that constitute the community of the CNCF, all contributing to projects and also sharing this same worldview. You know, that’s your peer group. And if you find yourself doing things that are substantially outside of the norm of the industry, you could land yourself very easily in a place where what you’ve built is so outside the norm, that you’re not going to be able to recruit people to work on it, you’re not going to you’re going to have trouble supporting it. Because you know, the core of the industry is over here, you’re over there in a corner. You know, now you’re sort of on your own, you’re you’re left, it’s sort of like a survival situation, we’re going to drop you on a desert island with a you know, survival knife and say good luck. there’s a there’s a lot of merit to being aligned to where the rest of the community is. And also, the reason that the CNCF has so many projects and so many members and such industry support is because it has these approaches work. They just do. You don’t have to forge this trail on your own. There’s a lot of paved road that you can take advantage of if you align yourself behind the cncf the projects that and again, there’s there’s a tonne of choice within that. It’s not like it’s one prescriptive path that you have to line up behind. There’s a lot of very, there’s a lot of variety and a lot of you know options within that path. But take advantage of the paved road don’t don’t go hacking through the forest unnecessarily.
24:48
Yeah, that’s good advice. And I think also it’s the one thing that you know, rather than the clouds driving the solutions, this is a set of solutions that have been has been adopted by the cloud. So I guess there is some kind of broader principles that are bigger than any one vendor, where the vendors are adopting even a large vendors are adopted the principles of cloud native giving that level of consistency now between each one, so then it is a bit more of a, you know, whether you’re on premise or whether you’re using a specific cloud vendor, as their as their leaning on the seat, the cloud native approach, then you’ll kind of then have a general a general equal way of delivering things across everything. To a degree, obviously, as we spoke about before.
25:36
Yeah, well, this, this gets back to your comment early on about not all commercial software was created by the vendor that sells it.
25:42
Yeah, exactly.
25:43
A lot of this stuff is open source stuff software that’s been lifted up and commercialised. And never has that been more true than the relationship between a lot of the services that exist on the cloud platforms, the big three that we’ve been talking about. And the the applications and services that are incubated or maintained by the CNCF. I mean, take a look at the landscape. I mean, there’s tonnes of them out there. You know, ElC is a great example. So Elastic Search, LogStash, and Cabana, is ELC stack. Those three technologies are part of CNCF and have been lifted up and commercialised in varying implementations, I think on all three clouds at this point. So you know, that’s, that’s an example of things that are happening in the community, they’re directly being lifted up and provided as simple, you know, one click platform options. So Kubernetes, I just overlooked that, that’s probably the single biggest one, that’s the one that’s eating the world. You know, we talked about ECS versus Kubernetes a second ago. ECS, Amazon built on their own, that was something that was completely Amazon development. It’s close, it’s closed source. Kubernetes was developed, you know, pretty much in the open, you know, Google started it up and then it became community developed. And now it’s, it’s everywhere. And I think it’s interesting to the point that we were talking earlier that Amazon sees merit and keeping both around. It’s not like it’s an either or proposition. This is what I was talking about lots of variety, is, you know, there’s a lot of paved road, but there’s a lot of different directions you can take that paved road,
25:48
Yeah, and I guess underneath, there’ll be, you know, it’ll be still using open source technologies. It will still be Docker, and, you know, all the other open source stuff. But I think, from their perspective, you know, if you were going all in on a cloud cloud vendor, which some of their customers probably have, and that kind of locked into ECS. And then they still want to run ECS on prem, then there’s a natural segue in to be saying, Well, actually, you know, if you, if you bought into it us a vendor, we can still support you on that trajectory, too. But again, like we’re saying, why lock yourself in? If it gives you the same outcome, why bother locking yourself in really? Like at least have some portability, if the outcomes are the same, and the efforts is just as minimal. Then it doesn’t really make massive sense to me to be vendor locked in if you’ve got to put the effort in either way. So I think there is a bit of kind of making the right decisions just to give yourself some future protection, because you can’t see down the road, and you might want to change, or you might want to take a service like I was speaking about before. But this, obviously, isn’t that but I guess this is how cloud native enables that style of approach if you kind of make the right tech choices. And then you’re also using cloud native, as a measurement and a marker of how you deliver the software.
28:47
Right. And, you know, my thing would say, or my opinion is that, whether you take the components of ELC and build it yourself on some infrastructure, and consume it that way, or you consume ELC through a platform service from one of the providers. Okay, you know, you make an informed choice there. And we’ve talked about, you know, different reasons you might want to do either or. The bigger thing is, you’ve adopted a tool that is fairly ubiquitous, which means you have, in a sense, hedged your bets against vendor lock, right? If you’re using these tools, whether they’re provided as a platform service, or whether you take them and build them directly. The way that those tools function should be more or less the same. You know, be aware for modifications here or there. But it’s it should allow you a good amount of portability without necessarily, you know, getting directly locked are tied into a specific cloud vendor. Again, caveat emptor, be aware of, you know, some modifications or things that may be be done to to encourage that. But generally speaking, you know this, the whole point behind this landscape is to provide you with choice and to provide you with tools that are vendor agnostic and portable. It’s right in the mission statement.
30:14
Yeah, exactly, I think is important. I mean, I’m not going to do, I’m not going to step in your toes with a storytime job. But I have a…
30:21
No, do it, do it!
30:22
I don’t actually have a story. But this is more of a brief history. And I think the principal, you know, every piece of technology is born from a problem that somebody is trying to solve. And I think the context of the problem is important to the technology. And sometimes people get hung up on the tech, and don’t really wind backwards to understand what drove the tech to be created to begin with. What problem was it trying to address? And I know, with Google, from them, it was obviously scale, and VMs. and managing the operating system and all the tools and the VMs. It was just very slow, right? So if you’re doing, you know, on demand scaling, you know, when they have an exceptional scale, then that wasn’t the most performant way to go about it. And then so they decided to kind of change the Linux kernel and introduce containers, or Aleksey, I believe at the time, where you could kind of compartmentalise certain elements within the operating system so that it’s isolated. So that was like a chroot jail almost. For those that are already familiar with Linux, I guess it’s like an isolated area of like networking and storage and processing and memory.
31:29
Yeah, BSD had jail, Solaris had zones. There were there were things that were sort of sitting around it but they Aleksey was really a it was a it was a focused or an opinionated way to do that sort of service isolation or encapsulation.
31:44
Exactly. And that that enabled them to obviously spin up lots of different processes in isolation faster on an existing OS, then tried to provision a holo s from scratch and then putting the app on right. So then it just became much more effective. Hence, Borg, which I believe is their internal platform, which is a corresponding one to Cuba natives itself, which is then around conceptualising, how these things got deployed, how they managed to scale up and down. And all these parameters that have done naturally kind of moved into Kubernetes as a whole. And then that predominantly was focused around micro services, but then with the operating systems, inside the containers, or Docker itself, which came along with a bit of a client server model. So things like Docker server talking to the Linux host, you know, and kind of carving out the Aleksey stuff, which is obviously Aleksey is no longer but so yeah, then it obviously modernised over time with the operating system. But then Things just got leaner and cleaner. So then it was like well, actually, we’ve gone from a full the MLS now into a Docker container LS of which now can be almost like a scratch container. So it’s then literally barely any OS at all really pretty much. And just your libraries and just your app. And that is it. And so the surface area got reduced, and things have just got more efficient over time. And that’s been the natural evolution. And then things can obviously move around and dev teams could obviously build things easier, and ci can build things faster, and testings faster. And these are all the benefits and the value from something that was more about scale, at the beginning for a company have now moved into like other benefits over time. But I think that’s kind of important to know, like where things have come from and and how things have moved over time to bring more value to different businesses. Because people just talk about them as if they’ve always, always, always existed. And everybody understands the problems that we’re trying to solve, but maybe they didn’t. So that was just deployed setup.
33:40
Yeah, no, I think it’s really good to understand that and that, you know, versions of that story, I think, are pretty common through the different. The different applications that you see on the CNC f landscape. I mean, at some point, a lot of them were leveraging some very low level fate, you know, there was some very, very low level functionality, you know, that existed in one platform or the other, or there was some process that you could you could accomplish a goal, but it was very complex and cumbersome and it didn’t work terribly well required a lot of specialised knowledge, a lot of the things on the landscape are really just trying to make things that are very low level of technical, very simple and accessible. There’s a whole like, sort of subcategory that cuts across all the categories that really are that, you know, it’s it’s taking, it’s taking stuff that exists but making putting a human face on it and making it consumable. Yeah. On the other hand, you know, there’s some stuff that was created really out of just seemingly nowhere. That is pretty great. To be honest. Like there’s a there’s a project that you and I are both pretty familiar with called crossplane. Yeah, that’s still in incubation. I believe it’s it’s early days. for that product, but shout out to those guys. Yeah, it’s a it’s a pretty intriguing service, you can go look it up, we won’t spend a bunch of time talking about it. But, you know, that’s not taking, in a certain sense. It’s it’s solving problems that way. But in another way, it’s it’s a completely new idea.
35:18
Yeah, I still think there’s an evolution to have, I think I think there’s still, you know, this is just my opinion, there’s there isn’t enough conventions. You know, I think Kuban, it is give it gave you some conventions is in like service and deployment. And so there’s some conventions over configuration, but there’s still a lot of configuration. And so I think, to kind of make it easy for developers, there’s some lacking conventions that port into these things that they just don’t have to worry about. And I imagine that’ll be the next evolution will be when IDs and other libraries are just kind of part of the development lifecycle. And it just, there’s just conventions that just happened that make this stuff work without you having to know it. But at the moment, it’s still very, very config lead. And so, you know, I still think there’s a maturity to a bit of a maturity path to go on with all this texture.
36:07
Yeah. And you can definitely see if you look at the landscape, this is another another observation. So for the categories that I would say are newer, or less established, those are the categories, oddly, that are the biggest. And it’s because they’re the ones that, you know, there’s the most people taking different opinions, trying things and trying to zero in on the right approach for any given thing in the landscape. So if you look at, let’s say, the continuous integration and delivery landscape, it’s pretty compact, it’s not, it’s not nearly as big as something like security and compliance, or observability, which is still like there’s a, there’s a big paradigm shift, there’s a big change happening from on prem to cloud, and people are trying new approaches. And so those portions of the landscape are a bit bigger, because they’re a bit more experimental, they’re a bit newer. And so if you look at the landscape through that lens, you can sort of just back up from it a little bit. And you can get a little bit of a heat map of Oh, okay. These are the areas where maybe there’s a little more innovation going on a little more experimental people are trying things, versus the things that are maybe a little more settled, not, you know, there’s there may be the, the rate of change is a little lower than the rest of the landscape. So just as a tip, if you’re looking at this, because it can be overwhelming. I mean, if you’re, if you’re looking at it, you can clearly see, well, there’s a there’s a zillion little icons here, what, what am I supposed to do with this, but if you look at it through that lens, now you it’s sort of like, that’s one interpretation of it. And it’s a way that you can gauge All right, so this is the space that’s more experimental, this is the place, it’s more settled, if we want to do something that’s relatively low risk. Let’s see if we can make use of, you know, the things that are either, you know, the most settled areas, or, you know, the areas where, if there is more experimentation, try and find the one that seems to have the largest community around it. Yeah. You know, to give yourself the most insurance, that you know, that is going to continue to move forward, you know, that just the landscape can help you in a lot of ways directionally in making some of those early architectural choices of what to include in our first pass, what not to include, again, I think what not to include is almost more important at this stage. But, you know, take a look at the landscape through that lens.
38:45
Yeah, and I think some of these texts you need if you’re going to be cross cloud, so that you know, where observability being one, where the cloud is, yeah, differs. So fundamentally, between each cloud, you know, how they do it, and the technologies they use that I can, you know, you’re going to be cross cloud, or you’ve got a bit of hybrid model, then sometimes it’s just important just to double down on a piece of tech that you’re going to maybe have to own the, you know, the cost of running operationally, just so you get some level of consistency and how the teams do observability. So, you know, if you do start thinking cloud native and looking at Cloud, native landscapes, certain tech choices just kind of make sense where the cloud vendors don’t really standardise in a specific way. So you kind of have to as a company around it with the tech choices. So I guess that’s the value of cloud native, really, if you are looking at it from that lens is, you know, there’s value to be had there where you don’t get the consistency from a cloud vendor. So you’re going to have to create it yourself with something in this landscape.
39:49
Yeah, absolutely. So you know, really just kind of taking a big step back from this, I would suggest that, as a team, you kind of take a look at this landscape rationalised. The services are the capabilities that you really need. You know, take a look at it from a heatmap perspective, figure out, you know, what’s, what’s the most mature options in each of these areas and start to place some educated bets. But I’ll go into it knowing that you know, are looking at it through the lens of if cloud agnosticism or vendor lock in, or some combination of the two are very important to you look at how you can consume these capabilities or these projects through a platform service, at least in an early stage, only because it minimises you error, it minimises the the amount of legwork, you’re going to have to do to learn all of the intricacies and the plumbing of these tools, you get whatever you can do to just directly consume it in an early stage and become more acquainted with it over time, you know, let you know is flattened the learning curve a bit, it will read up to your benefit, because it’ll allow you to prove value in your efforts faster than you know, trying to take on this huge learning problem of learning a bunch of different tools all at once, trying to become masters of all of them, while also proving business value. Yeah, so take this as a signpost it can guide you, but also look to ways that you can consume these technologies or these these applications in a simplified way, at least for now. You don’t have to stick with it that way, long term. But whatever you can do to flatten the learning curve and your first passes is that would be my advice.
41:44
Yeah, a lot of these texts are already integrated, you know, like excetera D being part of Kubernetes back end. So even though they’re on the landscape, some of them are naturally already integrated, even just in Kubernetes itself, on just how it how it works and functions. So I guess there is already decisions being made that flatten it a little bit in some contexts. But I totally agree with that, like, try and avoid all the learnings because, you know, there’s just no value in trying to operate all of this as if you are a cloud vendor.
42:12
Yeah, trust me, you’re gonna have enough to learn there. Anything that you can sort of chuck overboard, or at least chuck overboard for now and come back to it is probably better because, you know, try and keep you know, the main thing, the main thing and not get hijacked on diversions or you know, sort of off on a tangent. It’ll help you stay focused. And it’ll also help you from help you resist the that boil the ocean urge. That’s so easy to fall victim to.
42:45
Yeah, definitely. So have you got any other roundup? I guess, because this is gonna be a light one wasn’t it seeing as though we put everyone to sleep on the last one. And, you know, a bit like, let’s not go, let’s not go too heavy.
42:58
And well the last one was like War and Peace length.
43:00
It literally was, it was a trilogy wasn’t it, really.
43:05
Yeah, there were hobbits. There were shires. You know, we learned a new language. I yeah, it took a long time. So yeah, I’m good with this being a little bit … it’s a more contained subject. And again, this is something that, you know, our listeners are going to have to sort of define for themselves to a degree. But I think this is the biggest resource that we can provide, along with some commentary to make sense of the landscape. And again, as always, if you have questions or you have comments, if there’s something that Jon and I can do to help clarify anything that we’ve said, or you know, something that you’re seeing out in the industry, contact us, you can either email or tweet us. We’re happy to assist.
43:54
Yeah, absolutely. And the one thing I will say is, don’t let the technology lead the conversation. So just be careful. When it comes to cloud native, it’s not there to be any specific tech. And so a bit like I was just giving the history, it’s about the value and the impact that technology is going to have and the rationale behind it not just naming all the tech that you could name that falls into the cloud native bucket, there has to be value outcomes associated. Just try and reverse the conversation in terms of like, the outcome first, and I know we keep going on about this but it’s so important because this happens all the time; you get into a bit of a tech conversation, and not an outcome conversation that then helps you kind of work out the right tech to choose. It’s normally tech first but just get into the habit of it not being tech first i think is appropriate.
44:41
Yeah, I think that’s that’s good advice. I mean, the the landscape spells out a bunch of different technologies. But sitting behind all of those technologies is an implied process or way of working with that technology. There’s also an implied skill set that goes along with it. So don’t miss the process and the skill set component by being obsessed with the shiny object that is the the technology itself. Right? There’s other things that have to fall in line behind it. Again, when we were talking about making things consumable, you’re doing the exact same thing, but for yourself, right? You’re taking something that is relatively unknown or difficult for you today. And you’re learning it over time and making it consumable not only for yourself, but also for the other customers within your organisation, your your internal resources that are going to be consuming that capability. So give yourself some time to ramp up and be aware of that, that technology process and skill set, you know, triumvirate of what you’ve got to think about as you’re building things.
45:48
Yeah. And I believe in the next episode, although I stole your limelight earlier, you know, we’re going to discuss how to iterate applications, right. The software development practices that surround these technologies, which will then properly help lead on the tech principles anyway, because you’re defining the way of working, that’s best practice to begin with, and the tech should be slotting into that, not the other way around.
46:13
Absolutely. So on the next episode, we’re gonna start talking about modern software development practices. We’ve talked about cloud, the environment, how to organise your team, get some traction, define your outcomes, but when it comes to actually building the thing that’s going to run in the cloud, what is the front end of that experience? What is the developer experience? And how do you organise that work in a way that’s going to scale that is going to be sustainable in the same way that the cloud environment that you’ve now set up? So that’s probably going to be a two part episode to spare you the Tolstoy novels that we’ve been throwing your direction.
But yeah, we’re going to get into topics, in least in the first episode, like methodologies, what are the methodologies that are most prevalent in the industry that are sustainable and allow you to access that kind of developer and product velocity? product ways of working? How do you begin to think like a product company because you are building applications and by definition, you should treat those like products like products that you would you would sell, but you’re just selling it to an internal audience most of the time. And then the most riveting portion of what we’re going to talk about next is source code management principles. How do you avoid backing yourself into a corner with your source code, which is probably one of the worst things that I encounter all the time, people unknowingly backing themselves into corners or tying themselves very difficult to untangle knots.
So as always, please rate and review us on your favourite podcast app. If you have questions or comments, you can tweet us at @cloud_unplugged, or email us at cloudunpluggedpodcast@gmail.com. Going with that, find us on youtube at Cloud Unplugged for episodes, transcripts, bonus content and all sorts of other goodies we’re going to toss your direction. From that, thank you so much for listening. We’ll see you next time.
48:10
Cool, thank you very much. See you later.
Transcribed by https://otter.ai
