In this episode of Semaphore Uncut, we meet Nader Dabit, Senior Developer Advocate at AWS. He gives us his perspective on managed services in cloud development, tells us about AWS Amplify, and gives his predictions on the future of cloud computing.
Key takeaways:
- As the front-end ecosystem matures, more challenging products are possible
- Managed services give power to builders
- Prepackaged managed service collections help startups get going
- The 80-20 rule of cloud apps: 80% managed services, 20% differentiating value
- AWS Amplify users test apps on a local backend
- Infrastructure as Code allows incremental design of your production environment
- Startup costs reducing as serverless, pay-per-compute model takes over
- Nader’s future in decentralized finance
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello, and welcome to Semaphore Uncut. A podcast for developers about building great products. Today I am excited to welcome Nader Dabit. Nader, thank you so much for joining us. Please just go ahead and introduce yourself.
Nader: My name is Nader Dabit. As of this recording, I am working as a Senior Developer Advocate at AWS, and I’ve been there for a little over three years. And it’s an interesting week actually for me to be talking to you because this is also the week that I’m kind of transitioning into a new role, which we’ll probably talk about as well in a little bit.
Darko (00:35): Can you give us an overview of your career and milestones? What are you doing right now and what’s your main focus?
Nader: I started programming around 2012. I didn’t actually go to school for computer science. I’m a self-taught developer. Started learning how to code and got really interested in it. And from there I was kind of hooked.
I worked as an engineer for about five or six years as a developer at a few different companies. Then I started my own consulting company doing React Native and specialized in React Native for a few years. I wrote my first book called React Native in Action for Manning Publications and held the React Native Radio podcast for a few years.
I was really deep into that ecosystem for a while before diving into cloud computing. And in particular, full-stack cloud computing – bridging the gap between mobile and backend. Anything client-side and backend. Focusing on the developers that don’t have that backend or cloud computing background but want to build on the cloud.
As the front-end ecosystem matures, more challenging products are possible
A lot of the stuff that I’ve done in the past few years is to lower the barrier to entry for those types of developers. During that time, I’ve been at AWS for a little over three years. I started off as a Junior Developer Advocate. I moved my way up, and now I lead the developer advocacy team at AWS Front-End Web & Mobile. I’ve written a book called Full Stack Serverless, encompassing everything that I learned over the first couple of years.
Darko (03:14): What are the main challenges where people need to support either the frontend part of their application or their mobile application?
Nader: Two things are part of this conversation. First of all, front end. I would say the ecosystem has become larger and more complex, whereas the tooling has also become better at the same time. We have this thing where we’re having more complexity. But it’s also easier to get certain things accomplished versus the way we might’ve done those in the past. That doesn’t mean as a frontend developer, it’s easier to be a frontend developer. I think that as we improve the tooling and we improve the developer experience on the front end, we’re taking on more challenging things to do.
We’re giving ourselves more complex and a higher bar for the user experience, for the things that we’re building. So, therefore, while we’re improving the tooling and we’re improving the ecosystem, it hasn’t gotten any easier, in my opinion, to be a frontend developer because of all the things that we now have to take into consideration. You have single-page applications and dealing with the data architectures and routing and all of these different things.
Managed services give power to builders
We have these hybrid frameworks, the mixed client-side rendering with server-side rendering and even static site generation. You have quite a bit of things to understand how all this stuff works. So, taking that into consideration, how can we make people more productive without giving them even more things to learn? And that’s a big challenge.
Also, while it’s a challenge, it’s also a huge opportunity. Some companies are building out abstractions on top of the cloud and managed services that allow you to build out backend functionality. That used to be the job of either a single or a team of engineers that were very, very specialized. It can now be done by someone that maybe isn’t so knowledgeable.
For instance, a really good example of these managed services that have been around and a lot of people have probably used it, and it was kind of an early innovator in this area, is Auth0. Auth0 is a really easy-to-use authentication service. Now, imagine if you were a frontend developer and you needed to add authentication, imagine trying to build out something as sophisticated as that.
With Auth0, you can create your app and get the credentials, and they even give you code you can copy. So, those sorts of things are what I’m excited about, because then as a frontend developer, I can actually grab these different APIs and these different services. And I don’t have to understand how they’ve been implemented on the backend. As long as I can read their documentation, I can take advantage of all of that engineering talent, all of that power, all that complexity that’s hidden, and build interesting stuff.
Prepackaged managed service collections help startups get going
So, all of the stuff that I see happening is bridging this gap between front end and backend. It’s kind of falling into that category, managed services, databases as a service. And within AWS, AWS is complex. So for us to build out these types of layers on top of traditional cloud is a big challenge. I think that we’ve come up with a pretty great approach that has a lot of that complexity while also giving a lot of power to the developer. We’ve seen a lot of success.
A lot of startups want to take advantage of the entire power of AWS at some point. But when they’re building their initial version of their app, they just want to get up and running quickly, and they want to take advantage of all this stuff. But they don’t want to spend months and years learning how AWS works.
The 80-20 rule of cloud apps: 80% managed services, 20% differentiating value
Darko (08:11): So, user management authentication, that is solved. What’s the next step after that the developers usually want to solve?
Nader: I think the core bread and butter for almost every app is authentication, data, and storage. So, you need authentication for user management. You need a data layer, which is essentially a combination of an API and a database. And then you need some type of file storage, typically for images and videos.
If you can cover that really well, you’ve solved 80% of the problem for 95% of the developers out there. The other 20% is typically going to be the differentiating value that you’re going to be bringing in. And I think the interesting part about that 20% is that that’s where the traditional backend developer is going to shine. They’re going to be able to use their skillset instead of repeating the same thing and building the same API end points over and over and building the same authentication service. They’re going to be able to build out this differentiating value that can set them apart. Or, the other 20% might even be able to be handled by one of these services as well. It just depends on what you’re talking about. There’s machine learning services that you can buy into without having to kind of build yourself. There are video streaming services, there’s all types of stuff.
I think the main thing to kind of take into consideration for me is the trade offs. I don’t think there’s ever one right way to do something every time. It depends on what your existing skill set is. It depends on what you like to do as far as which companies provide the APIs that you enjoy working with, what is offered versus what you need.
AWS Amplify users test apps on a local backend
Darko (12:33): And for developers and companies who are working primarily in those stacks where you own everything – from the database all the way up – can you maybe guide us a bit through a developer experience?
Nader: I think it depends on what you’re building and I think that one thing to talk about right here is that most of the managed services kind of fall into this category of serverless. And for the most part, traditionally serverless infrastructure is harder to test than the infrastructure that you own.
But with Amplify, I can say that we have taken that into consideration. We do provide a local testing environment for authentication, data and storage, like I mentioned. So you can basically run a local version of your backend and you can test. We basically spin up a local mock graph QL server. We build out the local instances of your database and we provide a way for you to send mutations, send queries and things like that to your database. And also you can work with S3 locally, and then also you can actually mock a signed in user. So we provide a way to create a user and set up tokens and maybe even add groups and stuff like that for group-based access.
Infrastructure as Code allows incremental design of your production environment
Now, that being said, you’re still probably going to run into certain scenarios where you build out something that’s a little more complex that might not be supported by the local testing environment. It’s really easy to spin up a copy of your infrastructure because what you’re working with is infrastructure as code.
So, typically what people do is if they run into a scenario where they can’t test locally, is that they just create a fork of their existing environment. And then they’re able to test this in the cloud. And then whenever they have the changes that they want, you can merge the diff of your infrastructure’s code into your main environment.
So, typically the way the workflow is like you have a prod environment, you have a dev environment, and then you have a feature environment. So your feature environment gets merged into dev, tested and then dev gets merged into production.
Startup costs reducing as serverless, pay-per-compute model takes over
Darko (15:33): What do you see as the next step in the industry? And what’s next for you?
Nader: There’s a paper that I always reference. It’s called Cloud Programming Simplified, a Berkeley View on Serverless Computing.
In their view, they think all of the cloud industry’s headed to the serverless mindset or serverless implementation. So, I think serverless, the idea of people building out managed services and back ends as a service, is going to continue to become a thing.
They also think that in the future, serverless computing will be cheaper than managing your own servers. And also that serverless computing will be the default of the cloud. I think that the industry is headed in a direction of serverless. But there are still some problems that need to be solved in this space. And there are still some things like testing that aren’t completely fleshed out yet.
Many services are moving to pay per compute, and I think that makes a lot of sense. If we move everything into that model, and you don’t have to pay for anything unless you have users, it changes the whole dynamic behind running a startup. You no longer have to pay for this capital expense. You only have a variable expense. And that variable is the number of users that you have.
Nader’s future in decentralized finance
But as for me personally, I’ve been at AWS for three years and three months. And this is, I would say, the third iteration of my career at this point.
But I’ve also been really interested in the deep centralized finance spaces and DeFi. I have a lot of family and friends and stuff that are affected by some of the government restrictions and financial crisis that are happening in places like Lebanon. So, for instance, in Lebanon, if you have money in your bank, you literally can only withdraw a few hundred dollars a month. And while this is happening, inflation is going out of control.
So, your money is worth 10% or 15% less than what it was the month before. Actually over the course of the last 18 months, it’s around 1,100%. If you have $10,000 in the bank, you might now only have $900 of spending power.
And this happens all the time. Look at Venezuela, Turkey, right now all over the world, it happens, it’s a cycle. So, to me, the answer is some type of, worldwide currency that people can easily exchange and that holds its value against something else other than the U.S. dollar. I’m really interested in this space. And I also feel like it’s impactful.
Darko (23:17): Great, thanks Nader, this was a great overview. Wish you all the best in your next parts or part of your career as you said. And I also have to say that Nader’s YouTube account has a lot of valuable content. Thank you very much.
Nader: Thank you, thank you. While I’m moving into this new space, I’m still going to be involved in the community and the cloud and server lists and Amplify space. So, I’m not going anywhere.
Darko (24:19): Great, thanks for sharing that.
