This is the first of a two-part blog series. In this post we’ll use Stackery to configure and deploy a serverless data processing architecture that utilizes AWS Step Functions to coordinate multiple steps within a workflow. In the next post we’ll expand this architecture with additional workflow logic to highlight techniques for increasing resiliency and reliability.
If you’ve built a serverless application or two, you’re probably familiar with the benefits of serverless architecture. You take advantage of already built, managed cloud services to handle standard application requirements like authentication, storage, compute, API gateways, and a long list of other infrastructure needs. You can spin up these resources in a matter of minutes and add your own specific business logic (usually as AWS Lambda function code).
With Serverless, it’s not the technology that’s hard, it’s understanding the language of a new culture and operational model. Serverless architecture has coined some new terms and, more confusingly, re-used a few older terms with new meanings. This glossary will clarify some of them.
Like many startups, Stackery is a small team. For this reason, employees often need to go beyond their official job title to ensure everything gets done. As the Stackery product matures and gains more exposure, we’ve seen an increase in customer support inquiries and decided to further refine our customer support process through the creation of a customer support rotation that rotates amongst the software engineers on a weekly basis.
Vydia is dedicated to helping creators gain more control over their audio and video content with a centralized tool for distributing, managing, protecting, and optimizing AV files. Vydia’s software team describes themselves as a “DevOps team first and foremost” delivering new features and updates in a tight loop. They are always in search of new ways to improve and modernize the development process.
We’ve all read those op-eds in the Smarter Living section of NYT about impostors syndrome. After all, they have been getting more and more traction as a new generation enters the associate-level in their career.
If you work in tech, you’ve probably heard that “team culture” is the most important thing for a successful organization. Camaraderie, trust, passion… a good team should have all that. And it’s hard to deny that loving the team you work with will make you more successful, but how do we build that? There’s no AWS product called TeamFront and it’s not sold on Amazon. How can we take camaraderie from elusive to undeniable?
One of the biggest challenges when adopting serverless today is mastering the developer workflow. “How do I develop locally?”, “How should I test?”, “Should I mock AWS services?”. These are common serverless questions, and the answers out there have been unsatisfying. Until now.
It’s hard to believe, but 10 years ago AWS had only five products. Chief among them, of course, was EC2. Although it feels a little quaint now, back then EC2 was an incredible offering. Anyone could fire up a server in seconds, install some code, and transform that generic server into any service one could imagine.
At Stackery, our engineers live and breathe serverless development every day. Because of this, we are constantly evaluating the current soundbites about it; when a field is expanding this quickly, it’s not uncommon to hear a generous handful of misguided assumptions. So, despite the increasing influence of cloudside development, there are still a number of declarations published every week that seem to amplify some common and outdated misconceptions.
