{"id":3675,"date":"2018-11-05T13:14:37","date_gmt":"2018-11-05T19:14:37","guid":{"rendered":"http:\/\/benincosa.com\/?p=3675"},"modified":"2018-11-05T13:14:37","modified_gmt":"2018-11-05T19:14:37","slug":"a-brief-history-of-on-prem-serverless-development","status":"publish","type":"post","link":"https:\/\/benincosa.com\/?p=3675","title":{"rendered":"A brief history of on-prem serverless development"},"content":{"rendered":"

My colleague Pete Johnson<\/a>, at Cisco has released a blog <\/a>about a project called FONK<\/a>.\u00a0 I wanted to talk a little bit about why its important.<\/p>\n

iOS Developers<\/h2>\n

Let’s first start back with the dawn of mobile application development.\u00a0 Pretend you are an iPhone developer back in 2008.\u00a0 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.<\/p>\n

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.\u00a0 For example, you want to keep the all time highest score for all players who have ever played the game with their avatar name.\u00a0 Bragging rights are cool, and you want your game to be cool.<\/p>\n

The problem is, you don’t have any expertise in this.\u00a0 You know how to write Objective-C but you don’t know how to manage servers.\u00a0 In fact, you have probably never even installed an operating system in your life.\u00a0 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.\u00a0 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.<\/p>\n

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.\u00a0 If you don’t know what POST or GET are, they are basic HTTP request methods.\u00a0 Read more here<\/a>.\u00a0 You don’t want to manage servers, virtual machines, or even containers.\u00a0 (Also, containers don’t really get popular until 2014 so we are still 6 years away from that).<\/p>\n

Backend-as-a-Service<\/h2>\n

What you want is a service.\u00a0 And in 2008 if we wait a little bit until 2011 then we start to see two cool solutions emerge for us:\u00a0 Firebase and Parse.\u00a0 Firebase was bought by Google and still lives on but Parse was bought by Facebook and closed down.\u00a0 Both of these two companies offered a Backend-As-A-Service for your applications.\u00a0 Really cool.\u00a0 Now you could just use their GUI and put in database calls and then call it with your mobile app.\u00a0 You didn’t have to learn about managing VMs and all that.\u00a0 It was great!<\/p>\n

The other thing that people start to realize is that it is good to accompany a mobile app with a web page.\u00a0 To make it consistent, it would be great if the webpage would call the same APIs as the mobile app.\u00a0 That way you only need to maintain one backend that both the web and mobile app can call.\u00a0 Great!\u00a0 How to do that?\u00a0 Remember we still don’t want to manage VMs, OSes, or even the stacks that run that.\u00a0 Well it turns out that AWS has offered us static web page hosting on S3.<\/p>\n

Static web page hosting on S3 doesn’t sound like something that would call APIs.\u00a0 But let’s understand what it is.\u00a0 Our dwarf game is now hiring a web developer who knows Javascript.\u00a0 When you visit a website that has javascript, the javascript doesn’t run on that site.\u00a0 Javascript runs on your browser.\u00a0 What happens is your browser goes to the URL and the URL gives you static HTML files.\u00a0 Some of those files are javascript, css, and html that execute on your browser.\u00a0 So we can actually host this in a public S3 bucket, point people to go there and they download the code.\u00a0 You get replication, durability, high availability and uptime for free!\u00a0 Still no VMs, no containers, no operating systems.<\/p>\n

\"\"<\/p>\n

Enter AWS<\/h2>\n

It is now 2014 and you are a smart person at AWS.\u00a0 You see this Backend as a service trend start to come and realize you could make some more money.\u00a0 You also notice that some of these backend as a service companies also call your own products like your databases.\u00a0 You’re also worried about the threat of Google and Facebook entering the market and taking more of your customers.\u00a0 What do you do?\u00a0 You build a backend as a service by stitching together your own services.\u00a0 The advantage you have at AWS:\u00a0 You already have some well known database services: RDS, DynamoDB, etc.\u00a0 You also own S3 and your customers are already using it for static pages.\u00a0 You also own API Gateway which allows you to call S3 services on the backend but it needs something a little more powerful.\u00a0 So how can you complete the picture?\u00a0 You introduce AWS Lambda.<\/p>\n

In December 2014 AWS introduced AWS Lambda and many people were puzzled by the idea of function as a service.\u00a0 What good was it for?\u00a0 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.\u00a0 No VMs, no containers, no operating systems.\u00a0 No expertise needed in running this.\u00a0 Just put code in their GUI and off you go.\u00a0 Since you already use S3 you can easily put your functions in AWS and you are golden.<\/p>\n

Let’s realize that this way of running applications is not the right way for every application.\u00a0 Remember our dwarf game is pretty simple.\u00a0 We just want to store the high score and get and receive it.\u00a0 We may chose to add user identities and logins later as well, and our app can handle that.\u00a0 But at some point if the complexity gets too much on the back end we’ll have to hire a backend engineer.\u00a0 But for now we can still run it all with javascript and put our backend on AWS lambda, API Gateway, and DynamoDB.<\/p>\n

Kubernetes<\/h2>\n

In 2014 something happened that probably wasn’t meant to.\u00a0 Google introduced Kubernetes<\/a> to the world and that was intentional.\u00a0 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.\u00a0 By open sourcing Kubernetes Google could make a splash and assert some dominance.\u00a0 That was intentional.\u00a0 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.<\/p>\n

Let me explain.\u00a0 To have an AWS experience on Prem the best thing you could do was OpenStack or some other do it yourself project.\u00a0 OpenStack was pretty complicated, to put it nicely.\u00a0 There were very few orgs that successfully implemented OpenStack on prem and so many people kept migrating to the public cloud.\u00a0 Kubernetes has been so impactful that companies that have tried to resist or compete against it have thrown in the towel and embraced it.\u00a0 Check out the list:<\/p>\n