My colleague Pete Johnson, at Cisco has released a blog about a project called FONK. I wanted to talk a little bit about why its important.
iOS Developers
Let’s first start back with the dawn of mobile application development. Pretend you are an iPhone developer back in 2008. You know Objective-C and you know how to make killer user interfaces and you make a fun game about dwarfs hunting butterflies. You release the game, the app is good, and you are happy.
As the game gets bigger you realize you’d like to add features to make it so certain parts of the game are stored in the cloud. For example, you want to keep the all time highest score for all players who have ever played the game with their avatar name. Bragging rights are cool, and you want your game to be cool.
The problem is, you don’t have any expertise in this. You know how to write Objective-C but you don’t know how to manage servers. In fact, you have probably never even installed an operating system in your life. So even though someone may be really good at spinning up VMs and putting NGINX on it and running some back end ruby on rails code, that is more hassle than you want. All you want is a backend that you don’t have to manage where the game can upload and retrieve all time highest player scores and display it.
To do this, you know you want a place in the cloud that accepts a JSON POST request to send the highest score and you want to be able to put a GET request to get the highest scores. If you don’t know what POST or GET are, they are basic HTTP request methods. Read more here. You don’t want to manage servers, virtual machines, or even containers. (Also, containers don’t really get popular until 2014 so we are still 6 years away from that).
Backend-as-a-Service
What you want is a service. And in 2008 if we wait a little bit until 2011 then we start to see two cool solutions emerge for us: Firebase and Parse. Firebase was bought by Google and still lives on but Parse was bought by Facebook and closed down. Both of these two companies offered a Backend-As-A-Service for your applications. Really cool. Now you could just use their GUI and put in database calls and then call it with your mobile app. You didn’t have to learn about managing VMs and all that. It was great!
The other thing that people start to realize is that it is good to accompany a mobile app with a web page. To make it consistent, it would be great if the webpage would call the same APIs as the mobile app. That way you only need to maintain one backend that both the web and mobile app can call. Great! How to do that? Remember we still don’t want to manage VMs, OSes, or even the stacks that run that. Well it turns out that AWS has offered us static web page hosting on S3.
Static web page hosting on S3 doesn’t sound like something that would call APIs. But let’s understand what it is. Our dwarf game is now hiring a web developer who knows Javascript. When you visit a website that has javascript, the javascript doesn’t run on that site. Javascript runs on your browser. What happens is your browser goes to the URL and the URL gives you static HTML files. Some of those files are javascript, css, and html that execute on your browser. So we can actually host this in a public S3 bucket, point people to go there and they download the code. You get replication, durability, high availability and uptime for free! Still no VMs, no containers, no operating systems.
Enter AWS
It is now 2014 and you are a smart person at AWS. You see this Backend as a service trend start to come and realize you could make some more money. You also notice that some of these backend as a service companies also call your own products like your databases. You’re also worried about the threat of Google and Facebook entering the market and taking more of your customers. What do you do? You build a backend as a service by stitching together your own services. The advantage you have at AWS: You already have some well known database services: RDS, DynamoDB, etc. You also own S3 and your customers are already using it for static pages. You also own API Gateway which allows you to call S3 services on the backend but it needs something a little more powerful. So how can you complete the picture? You introduce AWS Lambda.
In December 2014 AWS introduced AWS Lambda and many people were puzzled by the idea of function as a service. What good was it for? Why would you want to call a function based on an event? If you keep in mind the entire architecture then you realize that AWS Lambda just completes the picture. No VMs, no containers, no operating systems. No expertise needed in running this. Just put code in their GUI and off you go. Since you already use S3 you can easily put your functions in AWS and you are golden.
Let’s realize that this way of running applications is not the right way for every application. Remember our dwarf game is pretty simple. We just want to store the high score and get and receive it. We may chose to add user identities and logins later as well, and our app can handle that. But at some point if the complexity gets too much on the back end we’ll have to hire a backend engineer. But for now we can still run it all with javascript and put our backend on AWS lambda, API Gateway, and DynamoDB.
Kubernetes
In 2014 something happened that probably wasn’t meant to. Google introduced Kubernetes to the world and that was intentional. After all, nobody was using their cloud and they wanted to make people realize that they could use containers on their cloud better than anyone else. By open sourcing Kubernetes Google could make a splash and assert some dominance. That was intentional. But what wasn’t intentional was that when 2015 hit and Kubernetes 1.0 was released it actually started adding some parity between public clouds and private clouds.
Let me explain. To have an AWS experience on Prem the best thing you could do was OpenStack or some other do it yourself project. OpenStack was pretty complicated, to put it nicely. There were very few orgs that successfully implemented OpenStack on prem and so many people kept migrating to the public cloud. Kubernetes has been so impactful that companies that have tried to resist or compete against it have thrown in the towel and embraced it. Check out the list:
- Google: Offered GKE, the initial cloud based kubernetes platform
- RedHat (now IBM): Completely threw away OpenShift PaaS code and built entirely on Kubernetes
- Pivotal: Had their own solution but now pushes PKS
- Azure: AKS Kubernetes offering
- Amazon: AWS who resisted and offered several different ways to manage containers (ECS, faregate, etc) finally offered native Kubernetes with EKS.
Many of these organizations probably would have rather liked to own the solution but everyone is now a Kubernetes provider! The way of the PaaS is dying. They are morphing into opinionated Kubernetes services.
But the biggest impact of all, to me, was that it started giving parity between public clouds and private clouds. The same Kubernetes platform that runs on AWS, GCP, Azure, PKS, could be run on your own data center on your own bare metal servers. You just leveled the playing field and made it easier for me to bring my apps back on prem. (If I wanted to, but of course why would I?) Well for the dwarf game developer, I have no need to go back on prem. But if I’m a big enterprise with lots of space in my datacenter, this might look interesting.
Kubernetes is simple to install, and much easier to manage than OpenStack, but still has its challenges. However, as enterprises mature, perhaps it won’t be so bad? After all there are solutions now from vendors including Cisco that offer Kubernetes with enterprise support.
FaaS, Object Storage, NoSQL, Kubernetes
Back to the mobile app world. When AWS lambda came out some people made a framework called serverless (check out serverless.com). People thought this whole function as a service thing was pretty rad. But now what makes it radder is we have a solution to run it on our own data centers using just Kubernetes.
I worked with Pete a little on his FONK project by submitting some code samples for the Guestbook app running on Kubeless. For a developer to not have to worry about creating Dockerfiles, Kubernetes YAML files, and being able to just write code and get it working it is very appealing. This serverless business is still pretty cutting edge and even though we are 3 years from when AWS came out with Lambda, there is still a lot of buzz about it and people jumping into the space. What I like about FONK is that it levels the playing field between what I can get on public clouds and private clouds. Certainly many people would argue that using a private cloud is the only way to go, but I see great dangers in this.
- I am not comfortable with a company as big as Amazon making even more money off of me and holding me hostage. I know they are good. I’ve used their stuff. I just don’t
- At a certain scale it is more cost effective to run kubernetes on prem than running in any public cloud. Granted you must have the expertise
- I can get better performance on my own datacenter. Sure if I have to burst, public cloud is great. But for chugging apps, I like my on prem stuff.
You can entirely disagree with me and you could be right. But just remember, in engineering it is always about tradeoffs. It’s not wrong or right. It’s what tradeoffs do you want.
