Return to site

Containers, Cloud APIs & Micro-Services 201

Mister Beacon Episode #113

· Mr Beacon

Imagine arriving in San Francisco from Milan, with a business idea and only money to last you a week. Next thing you know you are crashing at a stranger’s house, notably one that went on to found Uber...

Marco Palladino, now co-founder and CTO of Kong, did exactly that. Marco, with his co-founder, was able to build a network and even sign their first investment round at that kitchen table. In this episode, we learn about how their first company, Mashape, turned into the world’s most popular open source microservice API gateway, Kong. Kong is in the business of enabling ‘architectural freedom by connecting all microservices and APIs natively within and across clouds, Kubernetes, data-centers, and more’. Kong has 150M+ downloads of their open source product, 1M+ instances of Kong running per month across the work, and over 250 enterprise customers. Marco calls APIs the ‘3rd industrial revolution in this world’, the ‘assembly line of software’. Tune in this week for a crash course on containers, cloud APIs, and microservices.

Transcript

Narration 00:07

The Mr. beacon podcast is sponsored by Willie, scaling IoT with battery free Bluetooth.

Steve Statler 00:16

Welcome, everyone to the Mr. beacon Podcast. I am really delighted to have Marco Palladino, who's the CTO and co founder of Kong as our guest this week, Marco. Welcome.

Marco Palladino 00:31

Thank you, Steve. Thanks for having me here.

Steve Statler 00:33

Must be kind of a strange time for for you now. You know, we're kind of starting to ramp up and Italy had that terrible experience. And so actually our Director of Product Management is Italian he's going back to his family but you know, because we're this hotspot here in America used to go into quarantine two weeks ago back so how is it all impacting this, this virus.

Marco Palladino 01:05

But So first and foremost, it is a very sad global situation. I still have family in Italy, Italy was a hit earlier into the, into this pandemic. It seems like we're the country's recovering right now. The US us now is in bad shape. So what Italy was facing back in the days to go, we're facing it here now in the United States. It said, however you look at it. So I hope that everybody will come out stronger out of this from a business standpoint. You know, from a business standpoint, two things have happened. The first reaction when there is something like this happening in the world is fear. And so the first instinct for everybody in the industry and the users and the customers we're working with was fear what's gonna happen? What's gonna change and then usually fear They say fear, it's a it's an emotion even stronger than love, in a sense that, you know, it paralyzes you in a way that, um, you know, way that, you know, slows things down. But then soon afterwards, it was clear that in this world and if there is a new world emerging out of this, it is certainly going to be a digital world. And so organizations who are ready to address the digital challenges in a digital world where everybody's using their digital devices, and nobody can meet in person anymore. The companies that already are the ones that are winning the companies that the organizations that were behind in their digital transformations are the ones that are suffering right now. And so the second thing that happened is an acceleration of the digital transformation projects that these organizations are were implementing, they accelerated it, because this was a great trigger for them to speed things up.

Steve Statler 02:57

Yeah, I guess if the goal is jealousy. If the Goal is manage your resources better your supply chain your assets, whatever you're the services you're delivering to customers, now is the time to optimize and get efficient. And that means very often moving forward with your project. So are you seeing? So did you see like a downward spike in revenue and then an increase? So what does it mean from a business perspective?

Marco Palladino 03:24

We we saw the first couple of weeks, you know, kind of a slow down, you know, because everybody's trying to figure out what what would happen. And then, you know, we're working with organizations that either already wanted to transform digitally, or do we're already in the process of doing that, have they done it and they want to increase efficiency. And so with the kind of customers that we're working with, what we saw was a couple of weeks of what's going to happen and then immediately afterwards, okay, let's do this. Let's do it quick. Because if we don't do it, we're gonna be out of business. And so they look at Kong and what we provide, as, you know, the look at as as partners in their digital transformation, which has been great so far. So, you know, revenue and momentum has definitely accelerated in the past few months.

Steve Statler 04:13

Well, normally we talk about radio technology and stuff that's very low down the stack. And but I've always believed in taking a holistic view of solutions. And the cloud is an area which I want to learn more about. I grew up I did my computer science degree in the 80s. So I was doing assembly language programming, COBOL, and C. And you know, these apps were huge monolithic things, and I thought we were moving forward when we add client server and load balances, but your company is, is thriving, and you're really rock stars in this serverless computing API container based world What I'd like to do in the show today is have you kind of give us a bit of a masterclass around some discussions and questions I had about the fundamentals of that technology. But before we get into that, and start picking your brains, I'd love you to tell us a little bit more about Kong. It's an amazing company. I had the pleasure of going to your developer conference last year. I'm really gonna miss I'm assuming you're not having a face to face Developer Conference this year.

Marco Palladino 05:30

Not not this year, but we're having a digital one the first week of October con summit.

Steve Statler 05:36

Well, last year's was amazing. Some really large enterprises, Cargill and GE talking about how they're moving to, to towards this more agile, efficient framework. And, and also the having donuts on door hooks was just an amazing thing. So it was very fun, great culture. Great company and you have got some amazing investors. Andreessen Horowitz, you've got Jeff Bay sauce, Eric Schmidt. How did you get from Italy to San Francisco and tell us a bit about the history of the company and how you got such amazing investors? And I guess, also, I'm fascinated by you build a massive community around what you're doing in the open source space. So I'd love to hear about that. But let's, let's start at the beginning. How did this all get started? How did you and your co founders meet and get started?

Marco Palladino 06:40

Yes, me and my co founder agosto, we met in Milano, you know, our early 20s through common friends and you know, we started a business in Italy. We sold it But as you know, Italy, it's not really the right place to build a technology company. You know, I'm a big believer that, you know, of course, you have to be in the right place at the right time. And surely, if if we want to start a food business or a fashion business, we'll probably move to Italy. But if you want to start a technology business, we need to go somewhere else. And Silicon Valley and San Francisco certainly is a is that kind of place. And so, you know, we're, you know, we're already 20s we didn't have much money around. So, you know, everybody asks me, how did you end up in San Francisco? Well, quite frankly, I just drove to the airport, took a plane. And so we landed in San Francisco with with money to stay here and survive only for one week, but the return flight was three months later. So as soon as we landed, we had to ask for help quite immediately, and we start emailing people and you know, asking for help to you know, we're not we're not from here. We didn't know anybody here. So we had to build our network from scratch. And these entrepreneur back then, he answered to our call for help. And he said, You know what, you know, if you guys want to stay at my place for a few weeks, you know, you guys can sleep at my place. And you know, I was talking to my co founder, I'm like, should we go to these dice glaze. We don't know these guy. Is it dangerous? I don't know. But do we have money? No. So we have to go. So this guy was Travis Kalanick. Before he started ubirr he sold the white swoosh back then. And then, you know, there was, you know, in between selling red swoosh and starting goober, who was helping entrepreneurs. And so it was ours and other folks helped us, you know, get infused into the network. We signed our first Angel round at he's on his kitchen counter in San Francisco. I mean, and that's how it started. Really, you know, we built our first product. We We We raised the first money. We got the first customers, but but the idea was different. When we moved to San Francisco back then, the idea was not to start an API management business or a connectivity business, the business was to do something else. So we came to the US with a company called mash shape. So mash shape was an API marketplace, which ended up being the largest API marketplace in the world. And developers could could consume API's and publish API's that Others have built and gave me a really behind to this vision was that was the realization that API's are a third industrial revolution in this world, you know, like the first industrial revolutions. You know, we we assembled together different components to build an assembly line really, and build cars and build and build bridges and build, you know, appliances. API's are the assembly line of software, we can take API's that somebody else has built from within your organization from outside of the organization and assemble it together to create new software. So Matt shade was this marketplace where developers could publish API's and sell API's and consume API's to build software in a faster way. And those were the years where we started to see API only companies growing up for the first time like Twilio. Right. And that was a was it was incredible to see. Now it turns out, turns out that we trust To microservices quite early in our journey, and we needed to build an API gateway that was powering all of these API's that about 300,000 developers at the time, were publishing and consuming on top of mash shape. And you know, mash a had an ape logo because it was mash ape. And so what's the most famous ape in the world can come can come and so we call the gateway COMM And we built it for ourselves. Um, you know, we open source many things back then. And we open source conda as well. So it turns out that our transition to microservices and the in the in the requirement of a very fast, lightweight distributed gateway that we built for ourselves. First and foremost was something that everybody else needed as they transition to microservices. So we open source con all of a sudden comm just exploding adoption. Developers from all over the world organizations asking guys for enterprise support and enterprise features four point where we decided to divest the API marketplace and fully focused on calm. So my shape nk became calm Inc. And that's how and that's how we we are now with, you know, with with with a with a current company, you know, coming out it's much more than just the gateway. But that's how it all started.

Steve Statler 11:15

So if I'm a developer and I want to get into business and I find an API that I think the world needs, I write it, I can still go to comm and use that marketplace to make it available to others or not.

Marco Palladino 11:29

Well, well, it turns out that the marketplace, the marketplace was growing from a user standpoint, but not as fast from a revenue standpoint. And we can talk about that, you know, monetizing the long tail of developers. It's a very complicated thing to do in this business. But long story short, the number of users was growing the number of API's was growing, but big problem, the number of the revenue was not growing as fast. So we decided to fully focus on Kong and sell the marketplace. One other companies focus on building the infrastructure, the next generation infrastructure layer for any organization out there who wanted to become an API first company or an API oriented company.

Steve Statler 12:13

So you had a lot of developers a lot of API's on the ecosystem. Can you remind me again, how many does it speak with messing

Marco Palladino 12:22

with shape we had, we had 300,000 developers and 10s of thousands of API's that were all being processed by calm. And you know, we transitioned to call we open source Kong in April 2015. And the company transitioned to come gank in 2017,

Steve Statler 12:38

you saw the 300,000, developers 10s of thousands of API's, and they had a need, they were selling API's, but they needed the gateway and infrastructure what I'm interested in two things one is just to understand a bit more about these API's and if you had to analyze them, I mean many many different API's. Eyes, but what were the clusters of functionality that people were implementing with these API's?

Marco Palladino 13:06

So let's take a step back, let's let's look at why people need something like this, as we know, every business is, is becoming digital, right. And every business, you know, everything is digital, everything is going to be offered via applications that people can access from pretty much any device, including IoT, including everything else, right. And when when something becomes digital, the most important thing to do is to make sure that the applications are reliable. So as a second step organizations that have a digital strategy, they're going to be improving the reliability of their applications by distributing them by the capital in the applications so that they can deploy faster they can improve things faster, they can scale the team in a faster way, when they become distributed, and when they come to the capital. As a result to that they introduce API's API's are an essential component for any reliable the capital distributed application that anybody's building in the world, no matter what industry that is, it'd be fat finance can be banking can be traveling and API's, they bring a set of concerns that we do not have, you know, traditional monolith that doesn't have API's and thirdly, natural API's. And those concerns are pretty much around connectivity. So once we have an API that goes over the network, the biggest problem is that we have the network and the network is unreliable by default. So how do we secure the network? How do we make it reliable? How do we observe the network? How do we encrypt the network? And then once we do all of that, how do we expose our API is over the network so that somebody else, a developer or a partner or an internal, you know, team can then consume the API. All of this tooling is tooling that traditionally, the application teams are building. So the application teams were building the applications, they were distributing the applications and the start of that effort, they were also becoming They're also starting to manage the network, quite frankly, managing the network should not be their job. So what happens is, the more applications we have, the more services we have, and the more fragmentation we have, because each team is basically reinventing the wheel when it comes to all of these API's that are created. So instead of reinventing the wheel and building it from scratch, every time we introduce a new programming language, or every time we introduce a new application, how about we delegate all of this to a third party component. And that third party component can either be an API gateway, or it can be a service mesh, depending on the use case where we operate them. And so really, when we built the gateway for Matt shape, literally, we built it ourselves. We had a microservices oriented architecture to run the marketplace internally. So we had a service that was dealing with the building a service that was dealing with a user management service that was dealing with, you know, all the different aspects of running a marketplace, and we needed to have a gateway internally. That was fast. That was quick that could go Do all of this together without us having to reinvent the wheel. Turns out that what we built for ourselves, it's something that everybody else's needs to build when they transition to API's, or when they transition to microservices, and especially after 2013 and 2014. In the industry, there was quite a market transition with Docker and Kubernetes in such a way that everybody can now transition to micro services without having to build from scratch the building blocks. And so they use containers like Docker to package their software, they use Kubernetes to abstract away the operations of their data centers, but will do they use to abstract away the connectivity that their applications are generating. And and they're coming to us to call to to abstract it away from everything that they're building and then manage it in a in an organized way, in a reliable way.

Steve Statler 16:52

So you've covered a lot I want to go back and tweeze apart a few things, explain a few things. Have you added Wait a few things on what you've said. But what I saw at your conference was there was a lot of very large enterprises that there you're just kind of looking at your customer list you have like Deutsche Telekom orange, Cisco, NASDAQ, GlaxoSmithKline. Beecham, so how much of what you're doing with is part of an exercise where they're trying to take monolithic legacy applications and break them up so that they can have some of the benefits that we'll get to doing that. And how much of it is facilitating businesses that want to sell services, you know, whatever it is a commerce service or, I don't know an inventory service for for third parties and I guess maybe I'm also interested in the degree to which you're seeing those very large companies, not just break down what they're doing for efficiency, but open up what they're doing and change what they're doing and kind of essentially getting into the API business. That's a lot in a question. But

Marco Palladino 18:18

organizations are moving away from monolithic applications to get all the efficiencies that we just spoke about. So that's obviously one major motion that we're seeing across our customer base. As soon as they become microservices. As soon as they transition to microservices. They introduce API's and so how do we manage all of that? So that's one aspect of it. But then there is a significant part of our customers that are providing those API's to either external developers to partners to mobile applications to even IoT use cases. We connect with Kong you know, 20 million cars in China, we connect with Kong you know, trains and ticketing systems where When there is a pre flight checks in on a plane that the pilots are doing that system is powered by Khan. So there is lots of IoT going on there as well. It's a lower case, it's over the place. So connectivity that we're offering at the edge connectivity that we're managing internally connected to the test will be distributed across the world, in order to be able to power or IoT devices, all of the above is being implemented in one way or another by the customer base. And quite frankly, these are as a founder, this is really what keeps me you know, what, what makes me excited about you know, waking up in the morning and going to work because I know that the the entire world economy is if it's not running on API already, it is definitely going to be running fully on API's and the market opportunity for Congress great income runs the real world. And that's really what makes me excited.

Steve Statler 19:51

Yeah, I mean, you you're changing the world and that's an exciting thing. You're changing the way these massive companies to business What I was trying to get a sense of is, to what degree are they doing what they're doing to? So for robustness, scalability, availability, and agility? Or are they fundamentally changing their business models? And are they exposing what they're doing to their customers through a world of API's?

Marco Palladino 20:30

Yeah, so that transforming the existing business to be API power. So API's certainly unleash new creative ways of, of, you know, API's provide building blocks that we can then assemble. Like I said, you know, assembly line basically, to provide new new revenue streams and new products in an easier way. But first and foremost, they're using API To transform and digitalize the existing business, the business where the money is being generated today, then as they do that, that creates an opportunity to create new products in a faster and easier way. Because if the core business is a AP API API or API, or you know, it's it's offered the API's, then it's easier to build the whole ecosystem around that in a much quicker way.

Steve Statler 21:27

Okay, I get it. I'm very good. I'd like to get into a bit more some of the terms that those of us who aren't at the center of this here and kind of understand what, what they mean. I'm just thinking, do we need to spend any more time on why people are doing this, it's probably worth just one last run of that. So in the past, you know, we had these monolithic applications. We you had Companies like f5, that were allowing people to have multiple instances of that monolithic application. But I think what you're enabling is, is more decomposition of those applications and how do you advise people? If I'm, if I am a company that's making food products and that sort of thing, and I have all these massive systems, how do they go about taking a legacy application and breaking it up into this new service containerized API driven system,

Marco Palladino 22:45

but usually, usually organizations, the capital, they're monoliths, into micro services using different using primarily three different strategies. One of them is what I call the ice cream scoop strategy. So when you have Big ice cream, you know box, what do you do you scoop out, you know different services out of your mind on it little by little, and you connect them together. So you don't do it all at once you do it slowly over time, which in my opinion has been one of the most successful ways to position a monolith into micro services. I'm doing it gradually and doing it by providing business value immediately to the organization usually creates confidence within the team that this is the right way of doing of, you know, proceeding and also gives confidence to the management of the organization that that transition to microservices is effectively something they should be doing. Some other organizations, it's that they keep the monoliths where they are in the build new applications in a micro service oriented architecture. And then they glue them together. They connect them together with a monolith. And they do that in a couple of ways. Either they create a set of API's on top of the monolith, that they will integrate with this new Greenfield microservices applications or they transition to event event based micro services. So they use events managed by a log collector, like, you know, rabbit mq, Kafka or Amazon SQL, or whatever that is to glue together the monolith, and this new Greenfield. So there's a couple of ways we can, you know, we can, we can, you know, connect a Greenfield with a brownfield. And then there is a set of organizations, very few, very few of them that decided to transition using the nuclear strategy, which is we're going to be removing everything and rewriting everything from scratch and is going to be micro service oriented, very, very waterfall oriented. I have not seen that happening a lot, but I've seen it. And usually, usually if the application is too large and too big, this is not the right approach. And, you know, there's a lot of excitement about writing everything, you know, because that's what engineers like to do you know, right. Thinking are better ways of building our software. But but but usually the business suffers from these kind of decisions you the ice cream scoop strategy, slowly decoupling the monolith, the most painful parts of the monolith into separate micro services. Usually that's the biggest and the most successful strategy I've seen.

Steve Statler 25:18

I see. Yeah, this is interesting. I love the micro, the ice cream scoop metaphor. And you also talk about pizza teams. This seems to be a theme here, what's the pizza team?

Marco Palladino 25:30

One of the reasons why we're decoupling monoliths to micro services is to be able to innovate faster, build faster, deploy faster, you know, when a monolith we deploy once every week, once every month, whatever that is, but we want to deploy 50 times a day, we want to play 100 times a day. So the model it's it's not, it's not the right architecture for that handles of velocity. So we transition to microservices so that we can build features faster so we can fix things faster, as we transition as we the capital and distribute our software into microservices. Well, we also the coupling distributed the teams that are building those micro services because now we don't have a large key that's dealing with this huge codebase anymore. But we have individual teams that are dedicated to maintaining and improving and building separated concerns separated microservices, among these, the greater picture. And in a pizza team is is a concept that's quite fun. Basically, it's a pizza team is a team that's as big, you know, as it's not more than 70 people, because ideally, you can fit them all with a large pizza box, right with a larger with a large pepperoni, you fill your entire team. So we have this small, the capital teams that are working on the capital concerns. And all of these teams are talking to each other via an API, an API that even internally has to be connected as to be secured as to be improved and signed, support, documented and signed support.

Steve Statler 27:00

So this, I was always intrigued by this idea of continuous deployment. And I'm, I guess you break things up and you don't have the monolithic. If you don't have a monolithic app, you don't have to do the monolithic transition to the new version of the app. What I'd love to hear a bit more about that what is a bluegreen deployment, for instance, is that part of this

Marco Palladino 27:27

when when we release a new version of any service, we want to be careful that the new version we build actually works well. And so bluegreen or cannery deployments are strategies that we can implement in order to be able to shift not all of the traffic all at once to the new service by slowly migrating the traffic. So if there is something that's that's not working properly, that is Not being caught up in our tests or integration suite, you know, we can quickly revert back without affecting the entire customer base. Now with bluegreen deployments, bluegreen deployments, it's a very simple concept. So we create a new, a new replica of the new version of the service you want to deploy. And then with the load balancer without the load balancer, stop pointing at the old version of the services start pointing at the new ones, right? And with cannery, we do the same thing, but we do it with small increases of traffic every time. So we transition 10% of the traffic, everything seems to be working again, fine. Let's increase to 20%. Everything works. Okay, fine, then 30%. And so over the course of time that you can find a window that you can specify, you can then shift the traffic towards the new version. But if anything at any point in time goes wrong, we can revert back right so we can go back to the old version two fixes this fix the new problem that has emerged in the new version. All of this are just some of the things we have to think about when we move to microservices deployment. deployments is one aspect of them observability and how we trace and monitor and log all of this is another one. Like in a monolith, you know, if we have a monolith and there is a bug in the model, it gives us a stack trace, which tells us exactly where the problem was. But in our micro service oriented architecture, the problem may not be in our service, maybe in somebody else's service that somebody else has been building perhaps in a different language. So how do we know where things go wrong, you know, micro service oriented architecture, we need to have an end to end trace that does exactly you know where things go wrong. And that's required if you want to move to microservices. So tracing security deployments versioning, chaos, engineering, you know, all of these are aspects that we have to build and implement. When we transition to microservices. Then of course, we don't have to build it from scratch. You know, that's and that's why companies like Khan come into the picture. You know, us like many other organizations that are trying to innovate. You Infrastructure space. We tell developers don't build that by yourself. But you know, use something that we've already built that we think is going to be a good fit for you so that you can focus on building the service, focus on building the application. And everything else comes out of the box, that connectivity, that security, that deployment strategy, all of that comes out of the box.

Steve Statler 30:19

Interesting. So what about so I think what you were describing, there is an example where a micro service, you're going from one version of the micro service to another version, so maybe the micro services is a caching system, or I don't know, authentication system. What about multiple services being transitioned concurrently? Is there kind of a framework or rules or best practice on how to do that because your application may be made up of hundreds of different services and presumably, you don't want to say is best practice to change one at a time or how do you coordinate multiple transitions.

Marco Palladino 31:02

And this is a very interesting question. Um, you know, like, like every transformation. And the transformation to microservices also involves three different aspects. One of them is the technology aspect. Okay, we're going to use Burnett is microservices. And that's a that's what we spoke about up until now. That the second thing that we're going to be changing in how other people are being organized to build the software, and we addressed that. And the question you just asked, touches on the third thing that every transformation brings to the table, and that is culture. Culturally, when we run a micro service oriented architecture that's distributed, that's the capital, we have to live with the fact that our system is always going to run in a partially degraded way. So there's going to be teams that are isolated from each other, making upgrades simultaneously in an isolated way. And all that we know is that as long as the API doesn't change, we don't care about implementation changes on there. So as long as the API keeps working, you know, we don't care what they change. And, and it is very important that as all of these happens simultaneously, there's lots of moving parts. There's lots of benefits. But on the other end of the results, lots of moving parts. As all of these happens, it's very important that the API's are not being disrupted. And that's all that the interface, it's not being disrupted. So as long as the interface is not being disrupted, multiple teams can make multiple changes at the same time, and everything will keep working together. But yes, if somebody makes a change that breaks the API, well, that that will cause the problems. Now we have to revert back to the previous version of that API, because we're not, you know, there are migration strategies we have to put in place to make sure that every other team upgrades to a new version of an API. In case we need to make a breaking change in API. So that's why. And that's why designing an API. It's not something that should be taken lightly. But you know, thinking about how the API many people build API's focusing on what they want the API to do today, but don't think about what the API should be doing tomorrow. Building an API that can support changes over time without being disruptive of existing clients that are consuming it. It is one of the most important things that an API developers should be doing.

Steve Statler 33:38

I want to go back to this thing that you touched on just now about the organizational aspect. So I see we have these pizza size teams that are developing these services. They're not reinventing the wheel, they can use API gateways and they can use some tools like Docker and Kubernetes, which I want to go back into those and explain to what those are, but on the organizational side? It seems like this this, this is a very important team, the DevOps team, are they the ones that are kind of accountable for the, the orchestration of these changes or explain to me where DevOps came from? DevOps didn't exist when I started programming. So what happened? Where did they come in? What do they do?

Marco Palladino 34:30

And so we we, the application teams that are in charge of building the applications, they need to be able to work very well with an infrastructure team. That provisions the resources they need in order to run the applications they're building. We don't want the application teams to worry about infrastructure. Because if they did, build the infrastructure in addition to build Applications would have a different infrastructure for every different application. So we don't want that. We want to be able to tell the application teens use whatever language you want. Use whatever framework you want, use, do what you want when it comes to the application code base. But when it comes to deploying it, when it comes to securing it, when it comes to offering that connectivity, when it comes to running it even do not build that infrastructure by yourself. But ask for an infrastructure developer or an input or an architecture team to provision that for you. Likewise, in the good old days, we were going to we were provisioning hardware in the data center. You know, we're building a new app, I need five racks. So I can run my application. Very similar concept, except the infrastructure is digital now. So I need I need three Kubernetes clusters running in these three different regions and I need a service mesh. Please provision me this as I build the app and a deployed on top of that infrastructure. Now once the infrastructure has been deployed, and provisioned. by an infrastructure team, the application teams not only has to run the application, but they also need to be able to upgrade it and you know, version it and do deployments. And in the end, then, you know, when it comes to the offer operations, there is two different approaches that organizations can take. They can still keep the infrastructure team as the, as the gatekeeper of work changes are happening. But that risks making the team the infrastructure team a bottleneck, because every every change the application team needs to make when it comes to rerouting the request now goes to the infrastructure team, which is going to be kind of a bottleneck into making sure that everything is fast and quick on or the application team has a degree of freedom that they can use to operate on top of the infrastructure that has been already provisioned by the infrastructure, which in my opinion, when done right, it's the best approach. So with the infrastructure developer will provision the infrastructure and it will create role based access control Rules, to give permissions to teams to be able to do certain things in the day to day of their operations that do not involve having to ask for anybody else to do it for them. But fundamentally, the person in charge of maintaining this infrastructure is not the application team. It's the infrastructure team or the architecture team or the platform team, you know, however you want to call it.

Steve Statler 37:24

So I want to go back and do a sort of quick one on one review on some of the terms that you're using earlier. So you talked about Kubernetes. Can you tell us a bit about the origin of that? What is it? Where does the name come from? Where was it developed? What's its role?

Marco Palladino 37:41

You see transition to microservices, it's something that we're hearing today. But the concept per se, it's actually quite old, perhaps even more than a decade old. The reason why we're hearing it today is because today it's being these pattern is more accessible to more people. And thanks to you Kubernetes and thanks to open source technologies that have been released in the meanwhile. But when we talk about microservices in general, it's a very, it's a very, in technological terms. It's a very old concept. Companies like Netflix like Amazon, like Google, that transition to micro services before anybody else even starts thinking about micro services. But in order to do that, they have to build their own tooling. So they you know, when you transition to microservices, you want to have we want to have a way to package our software in a standardized way, a way to deploy our software in a standardized way, a way to, you know, do all of these operations in a standardized way. So prior to Docker, prior to Kubernetes. These organizations internally with their r&d teams, they built their internal tooling to be able to do this. One of these companies, Google decided to add that one of their internal systems called Borg into Borg was very Google oriented and you know, very Google specific, so they decided to Take the same concept but abstracted away from the Google internals and offer it to everybody else. And that happened after a company called Docker created that standardized, standardized way to package our software, we look at Docker containers, basically, it's like, if we if I had to take 1000 steps back, it's like looking at an archive, zip file or a tar file that ships with the application and the operating system. So there is a standardized way to deploy our software. And then there is a standardized way to run this package software around and you know, it's not far fetched to think of containers and Kubernetes with the real world analogy of ships, containers, and you know, and container ships and the actual containers that we use for our merchandise and you know, in the global shipment business in the world, you know, it's a standardized way to put everything together in a in a in the same shape and form and then it's a standardized way to build chips are the underlying infrastructure that allows us to carry these workloads from one place to another similar concept as the real world ships and containers adapted to the software world. And so Docker create this new way of packaging the software. Actually, Doctor created an epi. That was the wrapping around a technology that was available since a long time and that was Aleksey in linuxworld. So they created a nice and easy to use API to make Docker to make containers container technology more accessible in the world. And Kubernetes released a new way of being able to easily deploy it and run operations on top of these containers. And all of a sudden, the entire world doesn't have to rebuild their own container system and their own orchestration system. But all of a sudden, they can use existing technologies in your open source ecosystem sound service to build in transition to microservices. So the revolution that Docker and Kubernetes have done was to make these things technology's easily accessible to the rest of the world. And I have to say that open source has been a driving force into this new market transition that is defining how we're building digital applications today. Open Source. Docker is open source Kubernetes is open source even Kong is open source, you know, Prometheus grafana, open source Jaeger zipkin open source open source is the driving force behind modern infrastructure. There is no modern infrastructure without open source.

Steve Statler 41:32

It says so Kubernetes I think there's like some Greek in there something to do with pilots or guiding orchestrating I can't remember the the the the origins but you have these containers of software I kind of think of make files from the old day of how do you extract and deploy the software is Kubernetes doing load balancing failover where does that fit in this architecture

Marco Palladino 42:04

Kubernetes provides primitives that we can use for service discovery for, you know, load balancing for for all sorts, all sorts of things. But I guess the biggest, the biggest benefit that Kubernetes provides is being able to first and foremost being able to make many virtual machines look as if there were one computer. So when we deploy our software, you know, Kubernetes deals with the orchestrating where that workload is going to run on what underlying virtual machine. But when we deal with Kubernetes, we use the Kubernetes API and Kubernetes abstracts away the underlying Google machine landscape. So Kubernetes makes allows us to build a very large computer that runs in a distributed way. You know, that's that's one innovation of Kubernetes. And because it's being adopted by all the major clouds, the second advantage of Kubernetes is that it defies vendor locking or cloud locking, we can build something for Kubernetes. And it can run as well as on Amazon as well as Microsoft Azure as well as GCP, we can move it around as a matter of fact, we can also run it in our own data center, if we if we have a Kubernetes instance running sour. So these are the two, the two main benefits of Kubernetes. It really, it provides a few primitives out of the box that allows us to to create a modern infrastructure that can be used to deploy services, connect them together, load, balance them together, to play them together, and so on and so forth. Now, these primitives per se, they're not super intuitive for many people out there. So Kubernetes is the technology is the technology that any organization wants to use to build an internal platform as a service that they give them to the application teams, the application teams are there if you're familiar with Heroku, you know, Heroku was a very innovative back in the days because you just get Push your code and somehow somewhere that code would be the point. What infrastructure teams or platform teams in every enterprise organization should be doing is using Kubernetes as a framework to build a path that they offer to their internal teams. Right. But we definitely do not want the application seems to directly mess with Kubernetes. Because Kubernetes although it's very simple, it simplifies a lot of things, it can still be quite hard to grasp for, for people that have no experience with it.

Steve Statler 44:29

So the fact that Kubernetes is available on Microsoft, Amazon and Google Cloud Services is appealing. What's your view on the customers that you see their ability to span those platforms? No one wants to be locked in. I went to the the Amazon developer conference last year and it was frightening. It was frightening ly jhemini was just a sea of armies and armies of people. And I'm now wondering to what degree are these people trapped in? In, in the AWS land? and to what degree? Are they ever going to be able to switch? Are you seeing is that elusive? People building for cross platform independence? Or do you just have to give it up and say, Now I'm gonna kind of get addicted to these very compelling API's that they offer the only run on one platform or the other?

Marco Palladino 45:33

And these in this question, we connect to my statement that made a few minutes ago, modern infrastructure is open source, because if we use open source software, some vendors they may offer an open source as a service right, in each respective cloud. But if we ever wanted to move away from a cloud vendor, and we use open source software that we can use any other asset Service version of that same software in any other problem. And that's why open source is the driving factor of modern infrastructure. And quite frankly, I didn't think of vendors like this, you know, installed vendors, they want the, they're going to be providing higher and higher level services, in order to be able to, and we're seeing these all around, you know, every even in Kubernetes land, you know, we're seeing that cloud vendors are extending Kubernetes to provide more features, more functions, hoping that, you know, what, we're not going to be moving to any other cloud vendor as long as we keep using those features that are not open source. And so, you know, organizations or organizations today, it's not a matter of, if organization today are already multi cloud, a specific product. A specific team may not be multi cloud because they decide to run on Amazon or Google or Azure. But from a holistic standpoint, your organization per se, it is multi cloud today. Not because it wants to, because it has two different lines of businesses, different themes, different products. Some of these are coming out of acquisitions. And some of these are using very specific services that the vendors are providing. Every large organization in the world is multi cloud. So I don't think that multi cloud is something that the application team has to worry about. Because rarely an application team, it still happens. But rarely, an application teams will be coupled their workloads across multiple clouds simultaneously are doing does happen. That multi cloud concern, it's a concern of the platform team, who is provisioning infrastructure for every line of business and every team in the organization. And those are the guys that are going to be dealing with all of these different varieties of environments. And so the reason why, you know, even Kong and kuuma, the service mesh that, you know, we're contributing to all these are platform agnostic. It's because we, our user is not the application team. Our user is the platform team. And that user has to deal with a multi cloud reality.

Steve Statler 48:03

But I realize it's pretty much the top of the hour. Do we have time for one more question? I just wanted to ask you where this is all headed? And it's an open question, but I'd be interested in your thoughts.

Marco Palladino 48:13

Maybe Maybe to Mars, we can listen. And everybody's gonna be listening to the three songs I, I mentioned before, I don't know, at the end of the day, you know, we are transforming to the main driver to any transformation is the business. We want to improve our business. We want to make existing customer happier, we want to target new customers, we want to increase our total addressable market. And to do that we transform our organization, we transform our products in order to be able to address the challenges that that we're being presented with. As we try to drive more business. The business is always the main driver. So we're going to be doing whatever it takes to make sure you We can provide reliable platforms and reliable experiences at the lower cost with the maximum efficiencies with the with, you know, in the in the best way possible. Today for some organizations, that means moving to microservices or some others means to move to serverless for some others means to adopt all of these different patterns. Where are we going next, we're going to whatever is the last, you know, the past with the last resistance and the less friction that allows us to drive more business and whatever that will be, that will be where we're going. And so I don't I don't predict the future. But but people who cannot predict it, perhaps they can build it. And so that's, that's what I'm focused on, you know, trying to build these future. Very good.

Steve Statler 49:45

Well, thanks so much for your time. Marco, great to have you give us a bit of a masterclass on some of the building blocks to what you're what you're making possible. So thanks again.

Marco Palladino 49:59

Thank you, Steve. Mars has a very dusty place so another one bites the dust. Well you in this case then the second son would probably be that's life by Frank Sinatra because you know, I'll have to find some motivations for me being stuck on Mars. That's life I guess the last song The last song would probably be, probably been this mission Dharma Vincero from Pavarotti, you know, being you know the one very motivational song, you know, to motivate myself when I'm stuck on Mars.

Steve Statler 50:44

Okay, do you do you listen to opera much in the normal course of events,

Marco Palladino 50:50

only when I'm stuck on Mars.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK