Kong Destination: Automation, 17 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Technical Career Advice Clone Yourself Through Automation to Get That Next Job

Description

Automation is required for our companies to manage their massive amounts of APIs with speed, quality and security while also scaling to new heights — but it’s also a requirement for your career progression. Between May and June 2021, over 16,400 technical API-related jobs were posted requiring automation skills. Join Reza Shafii, VP of Products at Kong, to learn about how automation is powering the next evolution of API delivery, skills needed to automate the lifecycle and how you can practice these learnings in your existing role with tools you are already using.

Destination: Automation is a free, digital event exploring ways organizations can embrace automation to make their applications and underlying tech stacks more efficient, secure and resilient.

A

Yes, all right! Well, hey! Thank you very much everyone and uh let me just dive in um so the title for this presentation is deliberately provocative, learn yourself through automation. So what what did we mean when we talked about that? Let's dig into that um really, who are you know? We are developers, we're architects, we're operators, we're sres, we're marketing folks in this field, um really we are the digital era builders.

A

So what does cloning ourselves through automation mean in uh in this context, and you know the way the way I think about this is really the the question comes down to. How do we perform our craft? How do we do our the development uh that we do every day, the uh working with teams to build solid architectures every day um and and more in a more automation friendly way?

A

How do we do that, and before I do that, I'm going to tell you about then um an anecdote, perhaps a story of a person and a dog.

A

This is a quote from varying venice who was a management consultant um in the 1960s and 70s, and he said the factory of the future will have only two employees, a person and a dog. The person will be there to feed the dog. The dog will be there to keep the person from touching the equipment, so obviously the division of warren here uh uh you know, is that eventually we'll get to a point where um most things will be automated.

A

um Now I would say that uh what what warren predicted missed a couple of elements and a big part of that is that people are still needed. People are still needed. They still need to manage these environments. They still manage the automated environments and equipments of a factory. uh In that case, um and all of the different touch points.

A

All of the different digital touch points that we day-to-day have to deal with, with all of the things that are automated around us are driven through apis through the building block of apis, and that's why, in some ways, the answer to the question of how do we perform our craft in a more automation, friendly way is really can come down to.

A

How do we more easily consume apis to automate the things we do and how do we as we consume apis, create interfaces and create services and digital touch points that are themselves automatable, which really translates into? How do we build consumable apis.

A

Now this shift to apis is something that has evolved if we go back to um you know, 20-plus years ago, with the rise of the world wide web, we were in an era where the question really was: is there a website for that any given entity any given business any given organization uh any given application even was more about? Well? Is there a website for that, and that was a big, a big step in our digital evolution.

A

We had websites as opposed to having to call people and having to go to uh physical stores and that that made a difference, but then, with the rise of the smartphones from 2008 and roughly 2015, or so the question started to also include: is there an application for that, um or is there an app for that uh really um and we started to become more mobile and be able to use our mobile apps and smart devices uh with more personalized experience on our mobile apps to be able to interact with things, but something happened right around the end of that era.

A

All the way to today that is quite critical, which is these apps. These websites started being powered by well-defined application programming interfaces by well-defined apis and from 2015 on you started, seeing maybe a little earlier, you started seeing the question shift to from. Is there a website for that to? Is there an app for that to? Is there an api for that, and that was a critical shift in how we are able to expand and improve the way we create our digital touch points and our digital experiences, and that was a critical shift.

A

Therefore, in the way we are able to enable more and more automation and we've seen this we've seen this and it's it's it's going. You know you can look at it multiple ways. One way to look at it. Just two examples, but there are more, is that this shift has created. Also a general move from monolithic to the distribute.

A

This move from monolithic to distributed is not just happening in the application architecture, we're moving from monolithic to microservices. If you look at big hotels- yes they're there still just like mainframes, are still there, um but we're moving now to a distributed way of actually booking um uh houses, um individual houses and even rooms in individuals, houses.

A

Banks went through those stages to atms and to individual online banking. You can go on and on.

A

uh You know, workspace, I'm talking to you right now through my home office and more and more people are talking through their their home office and that's because of this move from the monolithic to the distributor and really the fact that we have all of these capabilities available through apis throughout apps and websites that are enabled by apis and that we've gone through this distributed model um is really behind uh many of the privilege for those of us who were privileged to be able to weather uh the uh the last year and a half uh of covet, um it's really the the the engine behind.

A

uh Why we've been able to weather that the fact that we've been able to have remote classrooms? uh You know zoom runs through apis. uh The fact that we have been able to book accommodations in uh more isolated areas uh through airbnb uh and and move there and take a break the fact that we've been able to order everything uh online and dropped at our door. uh Amazon is famous for the jeff bezos addict of everything should be an interface and therefore everything should be an api, and therefore everything should be automated.

A

All of this automation at the end, the humans are still there, but the automation is enabled through apis. So going back to the question of how do you clone yourself uh through automation?

A

I would I would say the answer is: how do you enable experiences through your products that are enabled with apis start with the api, create that delightful api create that great experience at the api level and the experiences on top of that will more easily follow, and many more experiences can be created for a distributed way of doing things from there on.

A

And this this shift, these shifts really um have also been accompanied by different generations of what we call api management software. Going back to what we do day to day, um we had the first generation back in 1998 to 2008 that was really dominated by the oracles and typicals of the world, where the types of interfaces were dealing with were really what we called. You know: web services and soap-based services.

A

We'll get more into that, um then we came to the 2008 to 2015 era, where there was a second generation of api management solution that that were brought forward, and now we really are in a third generation into an api management world. Let's talk about what that means, that means that we've moved from business transformation, digital transformation to digital transformation powered by microservices transformation.

A

Why is that? Well? What's happening? Is that as we are moving our applications from this monolithic architecture to microservices architecture, the number of different components that form the backbone of these applications is increasing almost exponentially.

A

So, therefore, the number of different processes that actually need to talk to each other that need to have that remote invocation on the wire is increasing and that's a good thing because of all the good things we know about microservices.

A

It allows us to abstract the responsibilities of the different teams and highly decouple it and create this highly cohesive interfaces behind between them. That's great, but it also means now that every team developing a microservice needs to worry about connectivity. So, therefore, the connectivity concerns in our world are increasing also at an exponential rate.

A

What is a connectivity concern that means that everyone who's writing. A microservice needs to worry about how to secure that microservice. Everyone riding a microservice needs to make sure that the modern microservices they connect to are connected to reliably and if there's a failure in other microservice that microservices operations is not affected.

A

That means that every microservice needs to make sure that as the load on it increases it can scale. So we're now in this business of not just worrying about building business logic into every microservice, but having to build connectivity service as well and connectivity.

A

Logic comes in in three flavors connectivity at the edge. So if you're, exposing your microservice to mobile devices, to partners to the to the public hot that there's a whole different level of security and reliability and publishing and a polishedness to that, publishing that you need to have connectivity between apps within an organization behind those edge services. There are many apps with many microservices within them. How do you secure those again? A different dimension of connectivity needs there and then how do you uh protect the connectivity? How do you develop connectivity logic?

A

I should say within the app so within the building blocks of the actual application, which are really microservices.

A

And that means this shift to this way. Higher order of connectivity needs really fueled by containerization in some ways and talk about that in a second has really led to these different concern shifts. If you look at about seven eight ten years ago, the concerns that we were seeing from our customers around api management and I've had the fortune of being in this space for a while.

A

So when I say from our customers is from our customers from uh previous previous life work where things like well, I have a three-tiered app with a database, a middleware and a web app. How do I protect? How do I manage connectivity? The whole thing is running on virtualized infrastructure.

A

How do I move it to a single cloud provider? The interfaces that this app exposes are soap-based interfaces. I really like this thing called rest. How do I move it to a restful interface and how do I bring in a brand a single api management layer that protects all of my apis?

A

What we're seeing now is quite different. It's an evolution of the things you see on the left, which is how do we move our monolith to microservices? How do we start with a microservices architecture? How do we adopt kubernetes properly? How do we containerize existing applications?

A

How do we create microservices that can easily be containerized and run on kubernetes?

A

Multi-Cloud is absolutely a thing we're seeing so many customers come to us and say we have multiple clouds and we need a consistent interface to deal with these different clouds.

A

In fact, what is what I'm observing is not just multi-cloud is multi-kubernetes as well multi-kubernetes on multi-cloud and the ability to consistently manage all of the applications and the services built on top of these applications across all of these different cloud providers and different kubernetes providers and rest rest, you know was- was a great pattern for a remote apis, no doubt about it, but it didn't end up being the sort of savior that we all thought.

A

Many other forms of communication between remote processes have come to form graphql, especially popular for front-end developer uh developers. Kafka is kafka topics, kafka services are really apis. uh Grpc is becoming a big thing and that front-end single api gate no longer the case. Remember what I just talked about between the three types of connectivity.

A

We now need to do automation, api management in a decentralized way across multiple kubernetes name spaces across the the old virtualized environments, as well as with the front gate, and so the way to do that is also the answer.

A

Through automation, we've got to find ways to let the developers focus on their interface of choice, which is git and be able to focus on their business.

A

Logic, use specs api specs as the source of truth for exposing their services and the life cycle of those services and then automate the way in terms of validating those services in terms of deploying those services to the different types of connectivity that I was I was referring to and in terms of publishing those services to the right places, so they're, consumable and discoverable, and what's more, we got to do that in a very decentralized way across many different teams.

A

So we got to do it at scale and if you look at what kong is doing in the space, if you look at what our goal is is to enable this different transition at scale. How do we let developer development teams? App teams, um you know, have simplicity and be able to run and work with uh their their platform of choice, their their interface of choice, get and their ids of choice, while making sure that they uh follow the rules, so-called or the guidelines, and build proper interfaces and build consumable interfaces.

A

That is what and you're going to see sessions today about the kung offering and connect, but all of those sessions keep that in mind, because this is what we're trying to do. This is what we're trying to enable at the end of the story through all of the components of our platform, and if we can do this, if all of us can do this, if all of us can enable our developers, our architects, our operators to be more effective and more efficient and to be able to build these applications powered by apis, better and faster.

A

I truly believe that we're going to be able to take our experiences day-to-day to another level, we're going to be able to build better network operations center for managing forest fires, we're going to be able to get to uh commuter based smart cars to decrease our carbon footprint, we're going to be able to manage farms of uh of turbines for generating uh power and believe it or not.

A

We have customers doing almost all of the things that I'm pointing out to here today or building things that do that today and hopefully that will allow us to make a better world for all of us, and so with that in mind, I really hope you have a great experience with the rest of the sessions today and I hope you found this session informative.

A

I know the sessions will get very technical, some of them and get into a lot of details about our product line. I'm excited to be watching uh many of them um and and yes have a great day. Thank you.

A