Ep 29: Paul Chin Jr. Developer Relations at Begin

Joshua Proto interviews Paul Chin Jr., Head of Developer Relations at Begin.com, detailing his journey in the serverless world and providing valuable advice for aspiring developers.

Background
Q: How did you get to be where you are today; head of developer relations for Begin.com?
Paul Chin Jr.: One day, I decided I was going to learn how to write JavaScript. So I started with Node bots. I had never done any of it, but through watching YouTube videos, I joined my local community. I became enamored with web development, and the open source movements that I was seeing. And so after a couple of years of just practicing on my own, I was able to get a job with an enterprise consulting company. I learned a whole lot about the cloud there. I got started in 2015, so this was right when serverless was just kind of emerging.

Q: Have you only ever worked in the cloud area, or are you also bringing other experience?
Paul Chin Jr: I've always been a ‘business nerd’, growing up. I worked in consulting, and I worked at other startups in the entrepreneur realm, and was learning how to create side hustles and stand wherever I thought the business opportunities could be. That's what led me to learning how to develop web applications from scratch, because I kept seeing more and more opportunities.

Q: What does it mean to be head of Developer Relations? How do you approach it?
Paul Chin Jr.: I didn't even know that this type of role was out there when I first started to learn how to code. I thought I was going to be building websites every single day, and just writing in the code itself. But it turns out that the same path that I had to take, learning, and learning and learning, is something that will never stop. So there have to be folks out there who are willing to teach and get involved with the users of whatever product it is that you're making. You have to learn about them, where they come from, what they like about your product, and what makes it unique and fun for them. We take that feedback and we're able to make the service even better.

Tools and Strategy
Q: Is this approach one of your cornerstone modalities of Developer Advocacy, or is this just an effective way that you found to communicate these ideas?
Paul Chin Jr: The importance of making technology accessible is huge to me, because I grew up not having technology around all the time. Eventually, in high school, I did get a computer and I was able to learn the ropes of the internet as it were. I think there's a huge opportunity now with more tools that are easier to use, that can bring things as complex as AWS down to a team of two people. They get the same large, scalable technologies as a fortune 500 company with 200 developers. I've seen the same system architecture on a 2 person team and a 500 person team. That's something that consistently blows my mind about serverless, and all these new tools that are coming out to make that possible, they’re lowering the bar to entry for a lot of complex technological solutions.

Q: Do you have any tools that you work with or work on that you would suggest?
Paul Chin Jr: When I first started learning, I had nothing but a Chromebook. I took it to my local meetup, and they showed me how to get Lubuntu running on it. And then I was a noted developer all of a sudden; I didn't need a super fancy MacBook. I didn't need to go through 4 years of C++. I had a Chromebook and a browser, and I was good to go. Part of that is really what kept me going. I'm here to tell you loud and proud that the open JSF architect project is a great way to get started with serverless. If folks aren't familiar with it, you go to arc.codes, and it’s an open-source framework for building and deploying lambda functions.

Q: How do you approach clients who are in many different areas of their serverless journey, and teams and organizations, to use this as an institutional choice?
Paul Chin Jr: One of the amazing things that I learned from corporate consulting is that you either run into people who love adopting new things that have their pros and cons, and the folks who were, ‘I'm never giving up my tools. These are the tools I use’. Which is fine, but I think there are so many more new developers coming online now, and so many more use cases appearing in the business world, that there's not going to be just one way to do things. There are going to be multiple ways to do things.

Paul Chin Jr: What an architect does is focus on a few core things in AWS to help web developers. But to make the software for most of the use cases that your apps need, you're going to need a database; you're going to need some way to call it with HTTP, and then you're going to need your functions. Architecture is built around the idea that you have a few awesome services, and put them together in a way that ensures speed when they deploy. So when they get called, they'll be speedy, which takes away a lot of the extra work that comes around the service discovery for all of these ephemeral tools. Lastly for all your resources, depending on where they are, need an architect to help do the lookups.


Q: How do you handle convincing organizations to leave their treasured toolsets?
Paul Chin Jr: I like this aspect of architecture. I think with an architect, even if people wanted to get access to AWS services that aren't part of the core experience, they still can, and they can be extended with macros. Ultimately, all architects will do is take your code and then spit out cloud formation. It's that cloud formation that gives us the nicely packaged, deterministic artifact that makes deploys repeatable every single time.

Q: So it is a cloud formation running under the hood?
Paul Chin Jr: That's exactly right. It uses the SAM deploy serverless application model and it's just standard cloud formation, which is great for having something to check into your source control and a single place to keep an eye on the stack. Recently AWS announced that cloud formation stacks can now have up to 500 resources instead of 200. This means that originally, some projects could run into a resource limit if you were doing just cloud formation, but now we don’t necessarily have that problem,

Q: How much time does this save?
Paul Chin Jr: We can now deploy at super quick speeds. I don't know what the exact numbers are, but the difference with using an architect is that it’s purpose-built for web applications. So it’s great if you're looking for a solution that would also include some legacy containers, like the proxies we are working on right now. We've got a great solution for folks that also have mixed workloads, or they've got some stuff in containers, and they have some old legacy servers running. You can build an arc API in front of it, and then proxy all the other routes that don't directly go to the arc app.

Future
Q: What else can we look forward to?
Paul Chin Jr.: Well, folks are working on macros and making Cognito more integrated. We've got some folks that are working on being able to enumerate all of the resources that you've got going before deployment, so that we're going to be more flexible in switching out different file paths. For example, one source path that was in there by convention, but because of your build step or your bundle step, you want it to point it to another folder. We'll be able to have that kind of flexibility, and the trade-off is only going to be a more wordy app-doc file. For folks that are looking for that flexibility and that customization, we're going to go ahead and build that in and make sure that people can create a workflow that works for their tooling.


Q: Where this is all going in the future, in terms of no code and low code movement?
Paul Chin Jr.: My thoughts on the future are pretty bright. I think that it's going to be even easier to create apps within the next two to three years. We're going to see the ability for an architect style application with this new proxy method to combine arc apps, so you could imagine one arc app doing one thing and a second one doing another.

Q: How and where do you think we are right now, in that stage?
Paul Chin Jr.: One of the things that I think hasn't been used enough is the WebSockets feature. I gave a whole talk about serverless com last year when we are still having conferences and it was all about WebSockets, about creating real-time experiences and doing it serverless. I didn't have to set up my Express server socket, IO server in Node land; it was just part of the API gateway. It lives right alongside my regular rest routes and which is a cool paradigm. We use it to begin sending some data back and forth in a nice snappy way. This gives us another taste of what serverless could be like in the future. I do think that the no code, low code movement is just beginning; we haven't even scratched the surface of what people are capable of. We're still thinking, even for me who is now a couple of years into this serverless bubble.

Q: Do you think these tools are going to morph into something else?
Paul Chin Jr.: Well they're going to be using services like a glitch, they're also going to be trying out code spaces, and everything's going to just live in the browser. It is not going back anytime soon. I think that'll continue to get easier, and beefier clients that can do more and more will be more common. Eventually, you'll be able to create apps just by dragging and dropping modules.

Q: What do you think a likely path to what’s going to happen would be?
Paul Chin Jr.: I think my biggest takeaway for the future is that there's going to just be a whole lot more of everything. There's going to be more than one cloud, there's always going to be more than one way to do something, and the real innovations are going to come from people who are outside of our industry right now. Someone who hasn't been tainted by the current knowledge. And then they just decide, ‘I'm just going to do this thing because I can’. The honeycomb, I think, is that AWS has a no-code platform, so some business analyst is just going to pick it up, start automating some of the forms they have to fill out or data that they're collecting, then all of a sudden, they get a taste of that power.



Q: Are there any resources that you know of that people are interested in?
Paul Chin Jr.: We've got tons of learning resources. The big one is learns.begin Comm. It has some tutorials on there that will use the architect, the main architect site, arc codes, etc. It also has documentation there and some walkthroughs.

Q: Is there a tutorial place to find learning resources or tools?
Paul Chin Jr.: I'm trying to work on more example apps and publishing them on medium and Dev so we can get those out. And we have a ton of sample apps. If you want to check out those they're all in a repo. We have dash examples, where we have examples of using event functions to trigger asynchronous workflows and scheduled jobs. Also an OAuth, Crud apps, and we also have apps that are ready to go for any of your favorite front ends like Svelte React. I think with each framework that you try, you learn more about the ecosystem in general, and you learn more about the way you like to work. If you find a good way to work, then you want to find more pieces in that same pathway. I'm stoked on dropping my ID completely; I can use GitHub for everything and then go to code spaces and edit the code, right in my browser.

Q: Do you think there are times of inherent conflict between developer experience and organizational goals?
Paul Chin Jr.: I would say that, if you've been working in the cloud for a while, then you're very familiar with the process of migration. You’ll always have this inertia that you have to overcome as an organization. At the end of the day, it's not a technology problem, ever. It is the communication problems between people, and I would say that building serverless and building with these new services, it’s going to be more beneficial for your actual developers in terms of their experience. This is because they're going to get more control over their target deployments.

Q: Is there anything else that you're working on that you'd like to share?
Paul Chin Jr.: Listeners should check out architect codes. I got to mention it a million times because I was originally just using it as a community member, because for the longest time I was just using the serverless framework. It was the first one that I ran into. And then when I found architecture, I enjoyed it. I started posting questions on our architect's slack. So you can Google and find the architect's slack to join and ask your questions because there will be folks there to answer.
I’m currently working on the Nicolas Cage project again. I want to have a more complex starter app that people can use as a base; I just put out the first part of a blog series on dev two, about creating a login from scratch. And at first, you might be thinking, why would you do a login from scratch? Everyone's got their favorite library. Well, part of what makes this industry so great is that we can do things in multiple different ways. I've never done a login from scratch before, where you can take the request and the password and you have to hash it etc. I haven't done that before and I've always left it up to another library. But then being able to see it and do it so effortlessly on serverless was cool. It was a good exercise, and so I'm writing up about it and publishing those. Hopefully, it will end with a big Nicolas Cage surprise piece. So, stay tuned for that!