Why invest in backend developers when your customers don’t care?
The front end is where all the business value lives — serverless optimizes your organization for customer facing experiences
Welcome to “Serverless Superheroes”!
In this space, we chat with the toolmakers, innovators, and developers who are navigating the brave new world of “serverless” cloud applications.
In this edition, we’ll met with Joe Emison, the technical co-founder of BuildFax and a contributor to The New Stack. The following interview has been edited and condensed for clarity.
Forrest Brazeal: Joe, you’ve been writing about and advocating “service-ful” development for many years. How did you get interested in serverless as a technology, and how are you using it in your career?
Joe Emison: I started developing software 24 years ago. Since then, I’ve been a CEO of multiple companies and currently just started a new company as CTO with a co-founder.
I used to be a typical software developer interested in cool things, testing out new technologies, but as I moved more to worrying about cash flow — due to the number of times that we had trouble making payroll — I began to get much more interested in what I was optimizing for. In particular, I think a lot about how to spend 95-plus percent of our development time on things that are specific to our organization.
So I’m guessing that means a smaller operations team?
I view basically all of operations as undifferentiated heavy lifting. That doesn’t make me popular with operations people, but every single ops thing I can do at my scale is something that everybody has to do. I want my team focused on things that only we do and anything else that multiple other organizations do, I just like to pay somebody else to do. In some cases that’s not possible, but far more often than not it is.
But it’s not all about less ops, right? Serverless can also reduce the number of programmers you need.
Yeah. You have to hire programmers who understand that all the other departments in the company, like marketing and sales and accounting, are as just as good and just as important as they are. Having built a company that was acquired by another, much larger organization, I’ve learned that it can be hard to get established developers thinking this way. I just couldn’t stop people from writing undifferentiated code that added no value.
I find that new people are easier to train, but the main way I get around the problem is by just not hiring a lot of developers. That way they’re forced to focus on the code that creates value for the business.
Oh, and I only hire front-end developers at this point. I have been the sole DevOps/backend/middle-tier developer in the last two companies I started, and it’s been fine. That’s sort of how I limit the amount of back-end code that gets written, and force everything to be defined in configuration. We try to actively incentivize people to write as little code as possible.
You’ve written for years about the “death of the middle tier”. Can you explain a little more about what you mean by that?
I think that we have arrived at a place where, for standard web applications, our backends look very similar on a conceptual level. When I say “middle tier”, I mean you’ve got a database, you’ve got front-end client code, and then you have to mediate between the client and the data.
Either you serve up the client code if it’s a more traditional app, or if it’s a thicker client like a JavaScript framework you have to have this API layer that is just translating requests from the client into a database or datastore.
The API does access control, maybe rate limiting and protections against other unwanted intrusions, and all that code is exactly the same code written by everyone else. It’s painful to write, but it’s all the same. Even things like database design — there’s a huge amount of commonality there.
When you get to the client interactions, of course, you have amazing heterogeneity. Allstate’s app looks very different from USAA’s, because that encapsulates their brand. But the backend, as long as it’s fast and secure and private, the customer shouldn’t care what it looks like. And yet these organizations spend millions of dollars on undifferentiated back ends, and it slows everybody down.
In my opinion, all of that should go away. Instead, we have what originally were called “backends as a service”, which to me are so much more than just “functions as a service”. What most people mean when they talk about serverless is just executing back-end code on Lambda, and to me that’s such a crazy way of thinking about it.
It’s like we’re saying serverless is the same as how we did everything before, except now instead of running the code on one server, we have to break it into lots of functions and connect them and maintain them separately, and somehow that’s better? It seems insane to me.
I’d much prefer to approach serverless this way: the back end and the middle tier are undifferentiated heavy lifting. The front end is where all the business value lives, because it’s where all the client interaction is. And if we take that view, and we say let’s optimize our organizations for these great front-end customer-facing experiences, we ask: how can we spend as little time and effort and money on the back end and still have it work and scale?
I think Firebase and Parse were the first shots at “Hey, if you write this client app within the frameworks we have here, you don’t have to do anything with the back end.” My favorite example of this is Yo, that crazy social media app that was written by one guy who knew nothing about its backend. I think he probably took, like, a Udemy course in iOS development, telling him how to use Parse, and it scaled and and it worked. Firebase has similar stories.
And now, of course, we have AWS AppSync, which I think is the next generation of what Firebase and Parse were trying to do.
I’m building out a tech infrastructure using AppSync now, and I’m fairly confident that, where in the past I’ve been able to run about ten front-end developers with just me doing the backend and middle-tier development part-time, with AppSync I could continue to be the CTO, do all the backend and middle-tier code, and support up to probably about a hundred front-end developers before I would need a dedicated backend developer.
So let me play devil’s advocate (i.e., a typical Hacker News commenter), and say: “That may be great if you only have a few developers, but I’m working in a huge enterprise and I need everything to be customized. I could never turn my back end over to a managed service.”
I think there’s a really big hurdle for serverless adoption with large organizations that have a lot of existing code, but I think the difference is a people difference, not a technology difference.
I straight-up reject the notion that somehow as a large enterprise you need to touch and feel servers. However, I know that the developers at most enterprises are somewhere between best practices 1998 and best practices 2007, and I think if you want to take them to best practices 2018 you can’t jump the intervening years.
What’s in between? Containers?
I think one of the reasons why containers are so powerful is that for enterprises they’re a gateway that helps you bring people along. I think Kubernetes is ultimately sort of dead technology walking, just like mainframes, but it gets people moving in the right direction.
If you are running a large organization that has a lot of existing employees, and they’re good people and you’re not hemorrhaging $30 million a year, it’s likely that the right strategy for you as an organization is to say: “We need to go level up everyone on containers, we need to go invest in our employees, we need to get everyone to take this journey, and we may always be four or five years behind best practices, but that’s okay. We can still succeed.”
But on the other hand, if you are losing $30 million a year, and the whole organization is in chaos, you might as well start from scratch with a new team. In that case, if you pick the right people, you can jump straight to best practices 2018. I don’t think many enterprises would talk about it that way, but I’ve been there and I’ve seen that it is possible.
And you know what? It’s hard. There is no continuing education in IT or development today. It is so easy to graduate from college, get a job, learn from the people in that organization, get paid well, get promoted, deliver value day after day, wake up ten years later and have some jerk like me tell you that you’re ten years behind, and feel very offended.
As an industry we have no mechanism for bringing people along; we have no annual continuing education requirements like, say, doctors do. Not that they’re perfect, but at least they have the sense that you should be learning new things.
Especially in enterprises, there’s a lot of FUD swirling around about serverless, particularly the managed services we’ve been talking about. People worry about getting locked into a walled garden. They talk about the importance of adopting open source technologies, building on Kubernetes, rather than using a cloud provider’s native services. Do you think these are valid concerns?
This is where organizational alignment and focus are key. If you tell me “I’m really worried about vendor lock-in”, or “Gosh, we really should be using open source here”, how does that align with our company’s overall mission? If you tell me I’ve got two paths, open and closed source, and they cost the same and they take the same amount of time — great, pick open source.
But if you’re telling me “Okay, we have two paths. One of them is using AWS AppSync, proprietary code that creates a GraphQL interface to DynamoDB and ElasticSearch and Lambda and will get us up and running super cheap and fast”, and someone else goes “No, no, no, that’s a bad choice because it’s not open source — we need to run our own Kubernetes cluster somewhere and then we’ll write our own GraphQL API, but we’re gonna have to hire another team of back-end developers, we’re gonna need a team of operations people to run this” … well, if our mission is to deliver effective software to our customers, the AppSync option makes a lot more sense.
Now people will say, “Well, what happens if Amazon jacks the price up?” They’ll list all the bad closed-source things that can happen. And the answer is: Ah! Well, we should always have a risk register. So we absolutely on our risk register should say there’s a risk that Amazon jacks the AppSync price, that Amazon goes bankrupt, that Amazon gets acquired by another firm that we decide we don’t trust with our data.
We should enumerate all these things and then calculate the likelihood that they will happen. Then we should expose this to our non-technical counterparts, our board, and then we should figure out if it’s worth countering these risks. Because there are mitigations.
But in my view, the best mitigation over something like AppSync being closed source is just reimplementing the app using the equivalent service on Google Cloud.
A multicloud approach like that can be tough because of the higher education barrier, but also because of the feature gaps between providers. How would you rank the current cloud providers in terms of their serverless maturity?
Without AppSync, Amazon was still well behind Google and Firebase. With AppSync, I think Amazon is so incredibly far in the lead it’s unbelievable. To me, AppSync is the first example of the AWS ecosystem paying off.
Because now you can use DynamoDB streams and Athena and ElasticSearch … you have Glue to do transformations on the data… I feel like AppSync was like putting a main piece in the middle of a puzzle. It connects a bunch of things together.
I think certainly number two is Google Cloud. The main problem is Google Cloud is largely the same serverless platform as it was two or three years ago. Firebase Functions are finally GA, and they finally made the deployments a bit faster, but they still haven’t done the things that Amazon has done in the ecosystem. For example, you can’t send a Firebase backup to BigQuery, which has been a massive nightmare in the past for the applications I’ve had on Firebase.
Plus, there’s an amazing cultural difference between Amazon and Google. In Amazon, no one’s making any duplicate anything. But Firebase Functions are like a weird abstraction on Google Cloud Functions and I just don’t feel like the unified vision is there.
I have a lot of respect for Mark Russinovich, who’s the CTO of Azure. I’ve interviewed him twice, and he gets it: it’s these high-level managed services that matter. I haven’t seen it materialized yet, but if I had to bet, my bet is that Azure will pass Google in this. Maybe not in 12 to 18 months, but three or four years out my money would be on Azure having a better serverless ecosystem than Google Cloud.
Forrest Brazeal is a cloud architect and serverless community advocate at Trek10. He writes the Serverless Superheroes series and draws the ‘FaaS and Furious’ cartoon series at A Cloud Guru. If you have a serverless story to tell, please don’t hesitate to let him know.
