FwdConf is X-Team's asynchronous conference that ran from the 6th until the 10th of April 2020. This is a recap of its first day, where we talk with Rafal Wilinski, one of X-team's serverless experts and the creator of Dynobase, a professional DynamoDB GUI client.

In this interview, we discuss the state of serverless in 2020 and what it takes to build your own product as a developer. If you want to jump to the other interviews of FwdConf or listen to digestible audio snippets from each interview, click here.

You can read the interview below, listen to the whole session here, or listen via Anchor.fm.

The State of Serverless 2020

What is Serverless?

Rafal began by explaining that serverless allows developers to deliver a product faster than ever before, because there's no need to worry about the infrastructure of it all. Everything that has been strangling developers for many years, from building servers to system maintenance, is now being taken care of by Amazon, Google, or Microsoft.

Developers can focus purely on building the business logic that creates the inherent value of the product. Serverless allows developers to be agile and to innovate faster. You can rapidly iterate on your product, which Rafal thinks is the biggest selling point of the whole serverless trend.

The fact that you can create a feature, click commit and see it automatically deployed on a staging server, all in less than ten minutes, is pretty amazing. There's no more need to worry about permission, scaling, patching the OS, etc.

Serverless Isn't the Right Word

Rafal believes there should be a better word for serverless. What does it mean to be serverless? After all, there's still a server involved in serverless architecture. He's a fan of the term servicefull.

Servicefull works because it emphasizes the fact that developers are using services; they're gluing together services from different places into one product. Almost like LEGO, if you will. For the rest of the interview, we'll be using the term servicefull over serverless.

The Challenges of Servicefull

Because servicefull is so different, it requires a new way of thinking and a new way of programming your applications. Firstly, you need to realize that everything is temporary. There's no one central place where all the data is kept, that does all the computations, etc. Everything is dispersed in the cloud. Local doesn't exist anymore. You cannot just access your harddrive like you could with a traditional server.

Secondly, servicefull allows for a whole new architectural pattern. Rafal brought up the example of event-driven computing, where servicefull architecture lets you easily plug things into the system and unplug them later. It's much easier to scale too. Ten events per minute is no problem. Ten million events is also no problem. Of course, you need to learn and deeply understand such a new architectural pattern.

The Pace of Innovation

Rafal compared the current pace of innovation in servicefull to the pace of innovation in front-end development, where developers joke that there's a new framework to learn every month.

Every company has its own vision of servicefull. Some companies try to merge that vision into a multi-cloud solution that gives you all the features of the separate cloud providers.

In general, AWS is pushing its users to a servicefull approach. Amazon pretty much provides a service for every business need: machine learning, predictions, video streaming, etc. Anything you can imagine, Amazon probably invented it. Your job is to glue those pieces together. Other cloud providers are following this trend.

For example, AWS created a service called AWS AppSync and Amplify. They're a toolkit for creating REST and GraphQL APIs where you only define the schema. You just need a few commands; AWS does the rest, from creating databases to creating the API gateway to creating the fetching logic, and so on.

It's a step forward for the no-code movement, because developers write dramatically less code and leave much of the generic logic for the cloud providers to create and perform.

While the big players, those who have the money and play on economies of scale, provide innovation in their own way, Rafal mentioned that the open-source community is its own source of innovation too. They constantly provide and improve developer tools and are constantly improving how you can use the big cloud providers.

Too Much Reliance on the Big Cloud Providers?

Rafal acknowledged that many people fear vendor lock-in. Once you commit to using all these services, you're tied to a provider who then has leverage over you. If they raise their prices, many companies will have a problem.

But, historically, AWS has never increased its prices. If anything, their prices have only been going down. Rafal believes that we're all trying to do good while creating a viable business. AWS is doing everything it can to get more customers and won't act in such a way that will enrage its userbase.

Additionally, Rafal said that you can defend against being locked into a vendor by using architectural patterns like a hexagonal infrastructure. It gives you some level of freedom, although you need to commit to a vendor to fully unleash the power of the cloud.

Choosing Between the Big Names

Rafal believes that the cloud providers are inspiring themselves. They adapt based on what their competitors are doing. They might not be talking to one another, but they're borrowing ideas.

This being said, cloud providers differ in what they're good at. Rafal heard a lot of good things about Google's BigQuery service, which is used to analyze lots of data. Logically, if you want to use that particular service, you'd want your data to be on Google and not with another cloud provider.

Kubernetes is another aspect of this. While Kubernetes isn't per se a servicefull offering, it's mostly worked on by Google right now. If you want the most up-to-date Kubernetes cluster possible, you want to go with Google Cloud.

When is it a Bad Idea to Go Servicefull?

Sometimes, you can't go servicefull for compliance reasons. If you're a medical, government, or military company, and you don't want to share any information with other customers of the cloud (because you usually share servers with others in the cloud), then you won't go servicefull.

Additionally, people sometimes decide they just don't like servicefull because they don't like any of the cloud providers. It's an emotional decision instead of a rational one.

Finally, if you need a massive amount of computing power, whether that's with specialized chips or graphics cards, then servicefull might not be a great solution for you. You might need to get a dedicated machine. This is particularly the case for machine learning projects.

Preferred Programming Languages

Most Lambda functions are written in Python and Node.js. But there's also C# and Java. On top of that, AWS recently introduced Lambda Layers, which allows you to run any kind of language inside your Lambda function.

That created an explosion of creativity in the servicefull community. People started running Bash scripts, COBOL, or even C. So you can run anything inside a Lambda function right now.

What's a Cloud-Native Developer?

Rafal believes that the industry is moving away from the distinction between front-end and back-end. The barrier is being destroyed and their separate competencies are being moved into one role which Rafal calls a cloud-native developer.

Developers need to change their way of thinking. Instead of diving deep into one language, one framework, developers need to think broader. They need to know what the available building blocks are and how they can connect them. Knowledge of these services is going to be crucial.

Building Your Own Product

Success Can Be Frustrating

Rafal has been creating products ever since he started his programming career when he was sixteen years old. He loves having the ability to decide on the direction of a product.

When he was working for other companies, Rafal felt that something was missing. He was working from ticket to ticket, from sprint to sprint, merge, deploy, etc. There was no emotional attachment to the thing he was creating, which he thinks is essential. So he always made things on the side.

Rafal's first product was called Voxel Rush, which was downloaded more than two million times. It was a massive success and set the bar pretty high from the get-go. This caused lots of frustration for future projects, because you can't easily recreate success like that. Subsequent games were not nearly as successful, so he moved away from games.

For the next few years, he was coming up with ideas. Two or three a day, writing them down, thinking about them, and mostly concluding that they were almost all garbage. But he kept thinking.

Which Ideas to Move Forward With?

Rafal has a framework for validating ideas. He scribbles an idea in his notebook and then waits a week before he does anything practical. During that time, he thinks about competition and obstacles. He tries to validate the idea. If there's a red flag coming up in that week, he won't commit to it. If nothing entirely deal-breaking has come up, he takes an action.

Much of it comes from trying to solve problems that you and/or other developers experience. Rafal asked other X-Teamers whether they too struggled with the interface of DynamoDB, and they said yes. That market validation spurred him onward.

How did Dynobase Come About?

One day, a colleague invited him to a project for a new, exciting API powered by DynamoDB. The NoSQL database is unique in the sense that you don't see any machines, you don't see any containers, you don't see the OS. You can push data, query data, and delete data, and that's it.

Rafal and his team created a decent API, but they realized that the interaction with DynamoDB was frustrating visually. The product is excellent (Amazon uses it for its main business) but debugging something visually was really annoying. The UI wasn't there, particularly if you were working on multiple accounts.

So Rafal thought "there has to be a way." He kept looking and he realized there was no good UI for DynamoDB. So he started developing one himself.

He decided to make it a paid product, something that was entirely new for him, as he'd been working on open-source projects for many years. He was so excited about the idea that the first prototype came out in a month.

Of course, one part is engineering something, another is shaping it into a genuine product. Creating the marketing, the visual identity, etc... to make it sellable. Convincing other people that what you made is great is incredibly difficult.

At some point, Rafal felt defeated. The market was brutal and he didn't know how to move forward. But a very satisfied early adopter of Dynobase contacted him and offered to help him with this very problem.

They signed a contract where they'd split the profits (or losses) fifty-fifty and went ahead. It was a great decision. Dynobase now pays Rafal's bills and is seeing significant growth.

Rafal said that there's so much joy in people telling you that they enjoy using your product. It's a great way to meet other people, to collaborate with them, and to network. The product has become a gateway to something much bigger.

If you enjoyed this interview, please go have a look at our bigger post, where we summarize the whole conference through audio snippets, quotes, and Slack highlights. There's a lot more to be found there!

Over the next four weeks, we will publish similar summaries of the other FwdConf days and link them below. See you soon.