Stacks on Stacks

The Serverless Ecosystem Blog by Stackery.

Posts on Company & Culture

Using Curiosity To Find Your Best Self
Farrah Campbell

Farrah Campbell | February 13, 2019

Using Curiosity To Find Your Best Self

As Stackery’s Ecosystems Manager, a huge part of my work revolves around meeting new people and developing relationships with them for the good of our company. I love this work not only because I’m passionate about people and serverless, but also because it keeps my curiosity muscle strong. To be good at my job, I need to do right by my personal connection to curiosity and learning— but sometimes I get off-track.

Did you know that the average person spends just 20% of their day engaged in meaningful activities that make them feel fulfilled and joyful? The rest of our day is spent sleeping, working, doing chores and mindless decompression activities like watching TV. If you’re not mindful, you could even lose some of that precious 20% by letting unfulfilling activities consume more of your day. For example, we spend much more time working than reading to our children. We spend more time doing mindless activities than we do learning, or growing. For those who are juggling higher education and a full-time job, have more than one employer, or are the caretaker of a sick family member this time for self-motivated learning becomes even rarer and more precious.

Like many, I recently found myself in this very situation. Even as a person who constantly seeks self-improvement, I was beginning to fall into old habits, spending too much time on things that didn’t bring me joy. I could feel resentment flooding back into my life and my shield against life’s stressors was thinning. I wasn’t being true to myself and was no longer focused on personal growth. I knew something needed to change but was struggling to identify what that was.

The Talk That Changed Everything

I reached out to Andrew Clay Shafer (someone I consider a mentor) and asked what talk he was most proud of. He immediately mentioned his keynote at O’Reily’s Velocity NYC 2013 called There is No Talent Shortage. It’s largely about company culture but many aspects can apply to your personal life as well. It touches on the practices of purpose-driven organizations and was just what I needed to hear. My biggest takeaway was the importance of finding a way to be better each day and, crucially, that talent attracts talent.

As Andrew says, “success isn’t about finding the right people, it’s about being the right people.” What can you do, each day, that will lead to new skills, new understanding or other forms of personal growth? How much of your day will you spend on things that truly bring you joy or fulfillment? Continued learning and growth are competitive advantages in the world and you need to seize them.

To change yourself, you have to first figure out what moves your soul. We tend to focus on things we think make us happy, without stepping back and figuring out what happiness really means to us. This can be really difficult when we’re balancing children, our work commute, putting food on the table, and nurturing others. But it’s extremely important in the long run not to beat yourself up about personal growth, that kind of judgment is the last thing you need on top of everything else! If you are curious about a subject or area of your life to improve upon, that’s enough of a seed to start.

Using Curiosity To Grow

If you are filled with earnest questions, you’ll listen more and show genuine interest in others.

This research in personal growth and finding my authentic self led to a life-altering article by Todd Kashdan called, The Power of Curiosity. I want to share a little bit of what I learned from this article and how you can apply it to your own life:

Curiosity creates openness to unfamiliar experiences which can lead to discovery and joy. Perhaps more approachable is the fact that a curious mind can be nurtured and developed. Like any skill, the more you use it, the better you become at it. Soon enough, that skill becomes part of who you are.

Studies by Gallup show that employee engagement comes mostly from relationships and connecting with a higher purpose. People are born wanting to think, learn, and grow but oftentimes responsibilities get in the way. Listen to urges to explore: as our curiosity deepens, more opportunities emerge.

Curiosity also helps us meet new people and develop interpersonal relationships. If you are filled with earnest questions, you’ll listen more and show genuine interest in others. The best part is that the people you meet have a basic level of wanting to be heard. When they sense an authentic level of caring, they will respond by opening up and sharing even more. This leads to tighter bonds and lasting relationships in work and at home.

How To Practice Curiosity

You can invite curiosity into your life by practicing, nurturing, and cultivating it. The first step is building knowledge; seek to learn one new thing each day and that knowledge will feed on itself. Essentially, the more you learn, the more you will want to know.

Curiosity can also enter your life when you become more playful and learn to thrive on uncertainty. Think about how boring life would be if we already knew exactly what was going to happen. What if you knew the results of every football game before you watched it? Would you even watch it? What if you knew for certain what grade you would get on a final exam? Would you need to study? The uncertainty is actually what drives us most of the time, even if we are not aware of it.

However, living a curious life is not always easy or free of risk. Those of us that have a predictable and guaranteed amount of free time (where they are adequately rested, hydrated, and energized) are probably in the minority and the rest should be patient with themselves. Just start by doing your best to locate sources of freedom in between responsibilities: call into a motivating webinar on your commute home to decompress, subscribe to a new, interesting podcast and listen to it while you clean the house. Even just taking a short walk to clear your head and map out creative time down the line can help. Anything to satiate your interest and invest in yourself. This is what I did when I sought out Andrew’s advice and the aforementioned article and both were huge stress-relievers when I needed them most.

Human beings have been makers and community members since the beginning of time. I think we often lose track of this in the throes of modern life, which leads us to a cog-in-the-machine mentality. This is one of the fantastic things about working at Stackery, I’m surrounded by a team that not only works together on tough problems every day but is actually building a solution to help other engineers do the same! It’s very inspiring.

Take small risks, try new things, try looking at an old “truth” with fresh eyes, and see where that takes you. I am happy to be doing that at Stackery and look forward to every adventure along the way.

Serverless in 2019: From 'Hello World' to 'Hello Production'
Nate Taggart

Nate Taggart | January 04, 2019

Serverless in 2019: From 'Hello World' to 'Hello Production'

A Look Ahead

As the CEO of Stackery, I have had a unique, inside view of serverless since we launched in 2016. I get to work alongside the world’s leading serverless experts, our customers, and our partners and learn from their discoveries. It’s a new year: the perfect time to take stock of professional progress, accomplishments, and goals. The Stackery team has been in this mindset for months, focusing on what 2019 means for this market. After two-and-a-half years of building serverless applications, speaking at serverless conferences, and running the world’s leading serverless company, I have a few ideas of what’s in store for this technology.

1) Serverless will be “managed cloud services,” not “FaaS”

As recently as a year ago, every serverless conference talk had an obligatory “what is serverless” slide. Everyone seemed to have a different understanding of what it all meant. There were some new concepts, like FaaS and “events” and a lot of confusion on the side. By now, this perplexity has been quelled and the verdict is in: serverless is all about composing software systems from a collection of cloud services. With serverless, you can lean on off-the-shelf cloud services resources for your application architecture, focus on business logic and application needs, while (mostly) ignoring infrastructure capacity and management.

In 2019, this understanding will reach the mainstream. Sure, some will continue to fixate on functions-as-a-service while ignoring all the other services needed to operate an application. Others will attempt to slap the name onto whatever they are pitching to developers. But, for the most part, people will realize that serverless is more than functions because applications are more than code.

I predict that the winners in serverless will continue to be the users capturing velocity gains to build great applications. By eschewing the burden of self-managed infrastructure and instead empowering their engineers to pull ready-to-use services off the shelf, software leaders will quickly stand up production-grade infrastructure. They’ll come to realize that this exciting movement is not really “serverless” so much as it is “service-full” - as in applications full of building blocks as a service. Alas, we’re probably stuck with the name. Misnomers happen when a shift is born out of necessity, without time to be fine-tuned by marketing copywriters. I’ll take it.

2) The IT Industrial Complex will throw shade

The IT Industrial Complex has billions of dollars and tens of thousands of jobs reliant on the old server model. And while these vendors are cloud-washing their businesses, the move to serverless renders them much less excited about the cloud-native disruption.

So get ready for even more fear, uncertainty, and doubt that the infrastructure old-guard is going to bring. It won’t be subtle. You’ll hear about the limitations of serverless (“you can’t run long-lived jobs!”), the difficulty in adoption (“there’s no lift-and-shift!”), and the use cases that don’t fit (“with that latency, you can’t do high-frequency trading!”). They’ll shout about vendor lock-in — of course they’d be much happier if you were still locked-in with their physical boxes. They’ll rail against costs (“At 100% utilization, it’s cheaper to run our hardware”), and they’ll scream about how dumb the name “serverless” is (you’ve probably gathered that I actually agree with this one).

I’d rather write software than patch infrastructure any day.

The reality? The offerings and capabilities of the serverless ecosystem are on an improvement velocity, unlike anything the IT infrastructure market has ever delivered. By the end of 2019, we’ll have more languages, more memory, longer run times, lower latency, and better developer ergonomics. They’ll ignore the operational cost of actually running servers — and patching, and scaling, and load-balancing, and orchestrating, and deploying, and… the list goes on! Crucially, they’ll ignore the fact that every company invested in serverless is able to do more things faster and with less. Serverless means lower spend, less hassle, more productive and focused engineers, apps with business value, and more fun. I’d rather write software than patch infrastructure any day.

Recognize these objections for what they are: the death throes of an out-of-touch generation of technology dinosaurs. And, as much as I like dinosaurs, I don’t take engineering advice from them.

3) Executives will accelerate pioneering serverless heroes

Depending on how far your desk is from the CEO of your company, this will be more or less obvious to you, but: your company doesn’t want to invest in technology because it’s interesting. Good technology investments are fundamentally business investments, designed to drive profits by cutting costs, innovation, or both.

Serverless delivers on both cost efficiency and innovation. Its pay-per-use model is substantially cheaper than the alternatives and its dramatically improved velocity means more business value delivery and less time toiling on thankless tasks. The people who bring this to your organization will be heroes.

So far, most organizations have been adopting serverless from the bottom-up. Individual developers and small teams have brought serverless in to solve a problem and it worked. But in 2019 a shift will happen. Project milestones will start getting hit early, developers will be more connected to customer and business needs, and IT spend will come in a little lower than budgeted… And the executive team is going to try to find out why, so they can do more of it.

So my prediction is that in 2019, serverless adoption will begin to win executive buy-in and be targeted as a core technology initiative. Serverless expertise will be a very good look for your team in 2019.

4) The great monolith to serverless refactoring begins

While greenfield apps led the way in serverless development, this year, word will get out that serverless is the fastest path to refactoring monoliths into microservices. In fact, because serverless teams obtain significant velocity from relying largely on standard infrastructure services, many will experience a cultural reset around what it means to refactor a monolith. It’s easier than ever before.

While “you can’t lift and shift to serverless” was a knock in 2018, 2019 will show the enterprise that it’s faster to refactor in serverless than migrate. They will see how refactoring in serverless takes a fraction of the time we thought it would take for a growing number of applications. Check out the Strangler Pattern to see how our customers are doing this today. When you combine this method with Lambda Layers and the rapid march of service innovations, the options for evolving legacy applications and code continue to broaden the realm of where serverless shines.

5) Serverless-only apps will transition to serverless-first apps

“Hello World” applications in tutorials are good fun and their initial functions deliver rapid purpose without an operations team. They are great wins for serverless.

However, when it comes to building serverless business applications, every software team will need to incorporate existing resources into their applications. Production databases and tables, networks, containers, EC2 instances, DNS services, and more. Today, complex YAML combined with the art of managing parameters across dev, test, staging, and production environments hold many teams back from effectively building on what already exists. A note: Stackery makes using existing resources across multiple environments easy.

In 2019, serverless will serve you more.

In 2019, we’ll see enormous growth in applications that are serverless-first, but not serverless only. The “best service for the job” mantra is already driving teams under pressure to deliver results to serverless. We believe teams who want to move fast will turn to serverless for most of what they need, but won’t live in a serverless silo.

To conclude: In 2019, serverless will serve you more.

All of these predictions add up to one obvious conclusion from my perspective: Serverless is finally mainstream and it’s here to stay. Stackery already helps serverless teams accelerate delivery from “Hello World” to “Hello Production”. We’d love to help your team, too.

Hi! I’m Gracie Gregory, Stackery’s New Copywriter
Gracie Gregory

Gracie Gregory | December 05, 2018

Hi! I’m Gracie Gregory, Stackery’s New Copywriter

I’ve worked in various sectors of tech since graduating college in 2014 with a Russian literature degree and an appetite for something entirely new post-graduation. After meeting with a handful of Portlanders in various sectors of business, I landed a PR and branding role at The Linux Foundation where I stayed for years. At the risk of using a platitude, joining the open source community was like “drinking from the firehose” for someone used to reading novels all day.

Since then, my career has taken other unexpected turns but always within technology. Because I am primarily a writer, I’ve often lacked the hands-on experience that would make new concepts like cloud-native, Node.js, and yes, serverless, come naturally. While my right-brain sometimes limits my ability to follow along in this particular realm without asking 10 million questions, I do believe an outsider’s perspective is an asset to a tech company’s communication strategy. Since I approach most technological concepts as an outsider, the content I produce is positioned for a more general audience. If you enjoy learning, technical writing from a non-technical background is really a dream job.

I applied to work at Stackery in Fall 2018 for that reason: Serverless is a fascinating new corner of computing and much of the landscape is still burgeoning. Working at Stackery would mean I’d be challenged every day and surrounded by pioneers in the field. I thought it would be a humbling opportunity and indeed it has been. Every day is a crash course in modern software development, tech history, and the variegated nature of startup life.

Throughout the interview process, everyone was kind enough to assure me that it was ok if I didn’t fully “get” serverless that day. They all told me that the space itself was relatively new and that, if I were hired, I’d have lots of resources to call upon. While I was grateful for the team’s reassurance, it didn’t quell my anxious desire to better understand serverless computing right that second. I had created an account with Stackery and played around in the demo, which really helped me frame things. But I still had fundamental questions. It was clear I had to lay some major groundwork to be a worthwhile candidate. I did, however, come up with a few serverless comparisons while I was researching the company. This made the concepts easier for me to digest before interviewing with the team.

“I wouldn’t risk throwing any of those out there,” my friend said the eve of my final interview. “What if you’re way off-base? You’d look like an idiot.”

Since trying to avoid looking like an idiot is the soulful principle that guides my life’s path, I was planning to take this advice to heart. But when I actually met my interviewers, I quickly understood that this was an experimentative culture that encouraged trying things before judging them. When I met with Stackery’s VP of Product and Engineering, Sam Goldstein, I actually felt empowered to test out a few of my serverless metaphors to see whether or not I was on the track to understanding. I was pleasantly surprised that he said they were (at the most general level) apt.

If you’re an expert, do not take this too seriously. What I am about to say will, best case scenario, make me look like a newb. Worst case scenario, it will make me look like a n00b. For anyone non-technical who might have found our blog without a drop of serverless understanding, you have permission to use my Cliff’s Notes below. I hope this will clarify serverless computing and get you started with this amazing technology!

Serverless is Like Dropshipping

At the risk of defining a theoretically new concept with another theoretically new concept…dropshipping!

Dropshipping uses platforms like Shopify to allow hopeful online sellers to only tackle the parts of eCommerce they want. In most cases, this means curating and designing the layout of their store. They pick from a vast library of products that appeal to them/gel with their brand vision and get to outsource the headache of managing inventory to a warehouse. People have been doing this in eCommerce for a while but new platforms make it accessible to more people or at least help them get it up and running faster. Serverless is similar in that engineers are able to focus on their application rather than infrastructure. Like dropshippers, serverless engineers don’t have to worry about their “inventory” (i.e. implementing and maintaining infrastructure.) Both are something of a jackpot for those who want to focus more on the art and science of their work instead of the logistics or administration.

Serverless is Like WiFi

This comparison is for those who don’t understand what precisely the “less” in serverless means. Imagine you are an average American in 2003: right around when WiFi was solidified as the home internet solution. You want faster internet in your home and to access it easily and without complications. You’ve known about wifi for a while and finally decide to hook your home up but can’t quite conceptualize how the wireless part works. Will you still need a router? Will you need to become a sysadmin to use it? We now know the answers to be a vehement yes and no, respectively. Yes, you still need a router, but it won’t take up space; you’ll basically never interact with it. It’s upstairs in a spare bedroom or hidden in your TV stand. Out of sight, but still enabling you to check your email and watch Ebaum’s World videos (it’s 2003, after all.) Serverless is the same. There is still a server, it’s simply elsewhere and not your problem as an engineer on a daily basis.

Serverless is Like Modern Car Insurance

Stay with me here. Let me say upfront that serverless is obviously more interesting than car insurance but the latter is creating relevant shockwaves in the industry. Ever heard of pay-as-you-go car insurance? Essentially, the provider sends you a small device to implant in your car. This allows them to track how much you drive and you only pay for the miles you use. This differs from traditional insurance because a) it’s cheaper and b) it’s a more lightweight solution. What I mean by this is, it’s there when you need it and not your problem when you don’t. Serverless is similar. You never pay for idle time, however, the tools are reliable and available when in use. Both are also beneficial in inconsistent traffic scenarios (… you promised to humor me.)


What’s the point of publishing all of the above, besides indulgently breaking down how my brain works? Well, the undergraduate class of 2019 gets their diploma in just six months and I can guarantee you that serverless will have expanded even further by then. I believe it to be the future of software development and writers are, of course, needed in this space. It doesn’t serve people like me to hear terms like “serverless” and write it off as a buzzword that’s above our paygrade; to do so would mean missing out on a fascinating subject to write about. So, if you work in marketing at any kind of company, I encourage you to start a dialogue with your engineering team. Learn from them and ask questions, no matter the beat you decide to cover.

It’s time for all of us to get involved in new technology as it develops. Serverless is a great place to start.


If you manage a software team and are interested in Stackery, set up a call with our serverless engineers today.

Stackery Welcomes Abner Germanow
Nate Taggart

Nate Taggart | November 21, 2018

Stackery Welcomes Abner Germanow

Today, I’m proud to announce Abner Germanow is joining us as the company’s first chief marketing officer (CMO). Like Chase Douglas, Sam Goldstein and I, Abner also hails from the halls of New Relic, where we all contributed in our various roles to making New Relic the market leader it is today. Abner has more than 20 years experience in global marketing, product and solution marketing. He has an uncanny ease in advocating and evangelizing technology as well as analyzing customer adoption of new technologies. I think because of Abner’s years of experience as an IDC analyst, he has this way of engaging customers, helping them pinpoint issues and then producing education and marketing campaigns to reach new customers.

I’m delighted to have Abner join the team. He assumes responsibility for raising up the company’s brand and marketing the tools that we have worked so hard to bring to customers. His experience in reaching the early adopters of new tech solutions and expanding and engaging partners in the AWS ecosystem are the same goals we have for Stackery.

We’ve come a long way since we launched at the Serverless Conference, one year ago in October. Then, I promised that we would keep building, refining and polishing. Making serverless better and easier to use. Now that Abner has joined us, he will help get the word out that Stackery + AWS help customers ship and iterate new applications faster than they ever have before.

Please give a shout out and welcome Abner. He’s @abnerg on twitter and we’ll all be at re:invent next week.

Scaling to the Challenges
Farrah Campbell

Farrah Campbell | November 01, 2018

Scaling to the Challenges

Can you create something by creating the appearance of something? Can a team increase its output by looking busy? Does “fake it til you make it” work with team culture?

It sounds ridiculous to suggest pretending can make it real, but smiling can make a person feel happier, and Botox can make a person less able to feel emotions they are unable to express.

When it comes to team culture, many managers work hard to create an appearance of inclusivity without creating the environment to support it. Writing mission statements is a lot easier than letting go of employees because they won’t use other team members’ preferred pronouns.

While this strategy isn’t always self-defeating, after spending years working on and building teams that support each other at every level, there’s one thing they all have in common: leaders who actively embrace humility.

More than anything else, a focus on humility and learning is at the heart of teams that function well:

  • Allows teams to shift their culture where it needs to go.
  • Makes change less intimidating.
  • Creates more opportunities to make the right career choices, as well as to assist others in making those choices.

Shifting to an Inclusive Culture

When I started the role I’m in now I felt woefully underprepared, but in retrospect I was being overly self-critical and a realistic self-assessment wasn’t really possible.

Teams that strive to hire people from different backgrounds can do the hard work when the team culture needs to improve. When I started the role I’m in now I felt woefully underprepared, but in retrospect I was being overly self-critical and a realistic self-assessment wasn’t really possible.

When we decide to put on a brave face and tell everyone we’re ready for a big challenge, the trick is being aware of it. When you first go out for lead engineer, you’re aware that you’ll be stretching your muscles, and the same should be true of your team.

You Don’t Have to “Fake it ‘Till You Make it”

Instead of misrepresenting where your team is at, try the honest version: “This is new territory for us but we’re excited to figure it out.” Or: “We’re aware that other companies don’t do a great job of this and we want to do better. We don’t have all the answers but we’re willing to learn.”

When you look at yourself as a pioneer ready to meet the challenges of new territory, pushing yourself to do better than your competition, team culture can be just as much of an ‘edge’ as technical innovation. So while I wouldn’t recommend dishonesty, I love it when teams admit they’re up for a challenge.

Creating Career Opportunities

It can seem so arrogant to overreach! To push ourselves to do something harder than before. But the awareness of that reach is what’s driven me to career success.

Because in the end when I was in unfamiliar territory, trying to make new and exciting business relationships happen for my team, I was fully aware that I was out of my comfort zone. That awareness led me to do the work and stay humble. It’s perfectly fine to convince others that we know what we’re doing, it’s when we convince ourselves that this is easy that humility can slip into arrogance.

Humility really is the key: if we maintain self-awareness then we know that success is not assured. We’re willing to do the research, to take good advice, and when all else fails to just ask for what we want or need to know.

No one writes a new web service that can take a million users on its first day. Success isn’t about doing the things we’re prepared to do, it’s about scaling to the challenges we’re brave enough to face.

What Successful Serverless Teams Know
Nate Taggart

Nate Taggart | October 10, 2018

What Successful Serverless Teams Know

Shipping serverless applications feels good. And it should! Serverless lets us focus on our software and ignore the tedium of managing servers. You download a framework, write a little code, and deploy your first Lambda function. Congrats! You’re a serverless developer!

But, as you run through that first “Hello, world” serverless tutorial, you might notice that you’re cutting a few corners that you can’t really cut in a professional setting. Security? Permissions? Secrets management? Dev environments? Testing? CI/CD? Version control? And the other two hundred little details that matter when you’re doing professional software development with a team.

On the one hand, these are solvable problems. On the other hand, though, if you have to re-invent the wheel for the development and operations cycle, maybe you won’t get to focus on the code as much as you thought…

Successful Serverless Teams

Successful serverless teams use software tools to solve these challenges. They deliver projects on time and reliably by automating the manual, error-prone parts of serverless development. While we could write a book on all of the best team ergonomics for serverless, let’s focus on the big three areas where you’ll want a tool: configuration, release automation, and visibility.

Configuration

Regardless of which framework you choose, once you get past your first “Hello, World” function, you’re going to have to start writing configuration code. Congrats! You’re a serverless YAML developer!

You (and everyone else on your team) will need to learn to configure every single cloud resource you want to use down to the smallest details. Event streams, VPCs, API gateways, datastores, etc, etc. And I mean really down in the weeds here – like, the be ready to map your IP Routing Tables kind-of-in-the-weeds…

The right tooling can automate this configuration for you and let you pull pre-configured resources off the shelf and into your framework automatically. That’s trickier than it sounds! Most “resources” are actually a collection of services. It’s not enough just to say “I need an API,” you’ll be configuring IAM roles as part of the assembly process, unless you have professional tooling.

Oh, and um, this is awkward… everyone on your team is going to have their own configuration file. Each developer will need to sandbox their own resource instances with scoped IAM roles and namespace their resources so you don’t overwrite each other with collisions. Even with master-level git-fu, this is really hard. That’s coming from me, and I came to Stackery from GitHub.

Release Automation

For serverless release automation, we’re going to need to figure out how to solve a few specific challenges: defining deployment stages, managing permissions, and integrating into a central CI/CD pipeline.

Once you’ve got your application built and your infrastructure configured, you’re ready to deploy. For your first app, that probably meant giving your framework God-like privileges in your personal AWS account. Yeah, ok, no, we’re not going to do that at work, in production. Right?

For serverless release automation, we’re going to need to figure out how to solve a few specific challenges: defining deployment stages, managing permissions, and integrating into a central CI/CD pipeline.

Managing deployment stages is a very similar problem to juggling your multiple configuration files. In fact, you could just define each stage in that one file… except that now when you make a configuration change, you have to remember to make it in every environment. I’m not pointing fingers here, but it’ll probably get messed up by someone at some point. And that will suck. Plus, these environments each have their own secrets and environment parameters which you’ll want to keep out of version control (and out of your config file) but available to the newly provisioned resources.

We’ll also want to create limited access roles for provisioning which, unfortunately, some frameworks just don’t support. This is why Stackery’s CLI leverages your existing user roles to enforce your access policy, rather than requiring admin rights to your AWS account like other tools.

Finally, while you could write your own scripts, scripting up serverless deployments can be tricky and brittle. With the right CLI tool, you can simply drop it into your CI/CD pipeline and have it automatically support your deployment stages and environment parameters.

Serverless Visibility

When you’re developing an application to run on static infrastructure (you know, the old way with servers), it’s pretty easy to visualize the architecture in your head. There’s an app; it’s on a server. If someone makes a change, the architecture remains stable. If there’s an error, it’ll show up in the server logs. Need metrics? Dropping a library or agent in one place will do the trick. Pretty straightforward.

With serverless, visibility suddenly becomes way more important. The dynamic architecture changes as your team builds more functions. Errors and performance bottlenecks can get distributed to other services. Logs and metrics collection need to be in place in advance – once that function instance dies, it and its data are gone forever.

It may not be obvious in advance, but the day will come when having a place to quickly glance and see a real-time view of your application architecture and performance will save you. Plan accordingly.

Get Back to Development

While we focused on three big challenges, the truth is that there are a lot. Centralized build process, dependency management, standardized instrumentation, error monitoring, and on and on. Pioneering teams have solved most of the above, for the rest of you, we’re making sure you can do all of the above without having to build it yourself.

The leading serverless teams today spent the last two or three years solving these challenges. Again, they are solvable. But if you’re trying to deliver your application and meet your deadlines (and not create a bunch of extra risk for your organization in the process), you have three choices:

  1. Give up the velocity advantages of serverless and go back to legacy software development.
  2. Delay the velocity advantages of serverless and spend the next several sprints trying to invent your own patterns (and then the subsequent ones refining them and training everyone on how to do it your way) and roll your own tooling scripts.
  3. Embrace the velocity advantages of serverless and plug in a software tool to manage these challenges and get back to development.

And really, that’s a pretty easy choice. Smart companies will always stand on the shoulders of giants and focus their efforts on building problems unique to their business. Try Stackery today and get back to development.

From Code School to Software Engineer: How I Got to Build the Future of Serverless with Stackery
Jun Fritz

Jun Fritz | September 25, 2018

From Code School to Software Engineer: How I Got to Build the Future of Serverless with Stackery

In 2017, I decided I wanted to become a developer. I felt that a code school could expose some popular trends in the tech industry, so I enrolled in Epicodus. I picked the first available track, and spent six months learning how to program alongside other aspiring developers. The bootcamp provided our cohort with interesting topics and applications to work on. I was completing the coursework and individual projects, but wasn’t spending much time considering what area of development I wanted to work in.

After Epicodus, I applied for any developer position in Portland that had the words “entry-level” or “junior” in the title. I had no preferences for what work I’d be involved with. I focused on large tech companies in the area and had the intention of adopting their methods and learning any tools that they used. The hope was that I would find a subject I was excited about from within the company. As a result, I held positions that I wasn’t interested in because I thought it would help my career and I’d be able to work my way up. I put off exploring my interests while at Epicodus but now I was out of the code school bubble. I wasn’t going to achieve much without an idea of where I wanted to end up.

I invested more time discovering what technologies interested me and what kind of developer I wanted to be. To stay relevant, I started looking into AWS and earned some of their certifications. I learned the ins and outs of services like API Gateway, Lambda, and S3. Eventually, I stumbled upon a tutorial that brought these three together to build a single-page serverless application. When I was done, it was clear that I wanted to focus on.

It felt good to dive into a topic like serverless and realize I wasn’t too late to the party. The serverless community was (and still is) uncovering ways to help it reach its full potential. I put together more serverless apps and payed attention to any area that I felt could improve. Each of my projects were prefaced with a hand-drawn diagram illustrating the cloud services I’d be using and how they all interacted with each other. It was my way of planning out the infrastructure and testing my understanding of the services involved. As my applications grew, it also served as a guide to navigate through the hundreds of lines of YAML that needed to be written. It helped shape my opinion that there should be other options for a developer to choose from when deciding how to build a serverless application.

I continued to form my opinions on what serverless development could improve upon and wanted to find any local developers who shared them. I entered the term “serverless portland” into my browser and followed a link that read “Stackery - Serverless Development for Teams”.

Landing at Stackery

I was relieved to find an engineering team that was building a toolkit that I wanted to use, but also curious to see how they were building it. So I expressed my interest in an email with some projects attached, and sent it off hoping that I’d receive some feedback. They reached out to me soon after that and I got to hear what problems Stackery was solving. A toolkit designed for teams to improve the way they built serverless applications. Part of me was upset over the fact that I hadn’t found the Stackery toolkit sooner for my own projects. Another part of me was determined to be a part of the solution that I wanted to see in the community.

Follow up discussions got me into the hiring process and I came out the other side a Software Engineer at Stackery. Now I’m a part of a group who share the same drive, and who want to make a positive impact in the tech industry. I wouldn’t be in the position I am today if I hadn’t parted with my initial mindset of “just get a job in tech and you’ll figure out your interests later”. And I’m confident that my work as a developer has more of an impact now because it’s backed by a desire to move serverless development forward. Earning a role on a team like this, in an area of technology that you’re passionate about, should be the goal of every aspiring developer.

How Do You Actually Create a Diverse Team in Tech?
Nicole Blystone

Nicole Blystone | September 19, 2018

How Do You Actually Create a Diverse Team in Tech?

It’s easy to say that you value diversity and inclusivity, and that it’s important that people from all walks of life of represented and heard from in your work environment. The perspectives a diverse team can bring to the table, along with the variety of tools and solutions, is appealing, and it feels good to be able to say that you respect and learn from those different ways of seeing the world. But it’s one thing to say it, it’s another thing to mean it, and it’s yet a third thing to actually demonstrate it.

So how do you walk the walk of an inclusive work environment rather than just talking the talk?

It’s not as simple as saying, “We are going to hire a diverse team!” While that sentiment is great, it doesn’t do anything to ensure that you’ll get a group of candidates that are actually from many different walks of life. Fortunately, there are lots of ways to reach diverse recruits in the age of the internet. Most major cities have groups of women, people of color, and other underrepresented communities who run organizations geared toward empowering professionals in their particular fields.

In Portland, for example, we have PDX Women in Tech. Their organization advocates for women to enter careers in the tech field, offers the ability to post jobs through their website, and helps connect women to jobs in a field that is often male-dominated. There are many other resources for getting job postings to diverse candidates, including hiring groups like Hire <Div>ersity, that can work as strategic partnerships to encourage diverse hiring practices.

More than just getting the word out through many channels, it’s important to make sure to discuss things like unconscious bias with your hiring team. Whether we mean to or not, it can be easy to form opinions about a potential recruit in advance based on things like appearance, age, race, gender, and many other factors. The process of judging a candidate can begin with something as simple as seeing their name before you even have a chance to meet with them. Making sure that any team members meeting with a candidate are aware of unconscious bias can help mitigate some of the damage these stereotypes can cause.

Conversations about the importance of diversity, including making sure that the team is aware of unconscious bias, set an important foundation for ensuring that everyone is on the same page about hiring goals. Transparency around diversity goals helps ensure that the existing team understand the importance (and benefits of) having people from a variety of backgrounds and representations join the company. Making inclusivity a regular part of the conversations, and making sure it is something that can be talked about opening, helps promote the idea of within.

Finally, one of the most important things a company can do to make sure that they are walking the walk of inclusivity and diversity is this: make your company a safe place for people from many backgrounds to be valued and to grow.

Improving the Workplace

There are lots of ways to create a safe place for employees. Create clear and open communication channels, and encourage people to use them (because, once again, transparency is important). Managers should work to make sure that employees have a voice in their work and in the decision making around it. Empowered employees feel a sense of ownership in their work and in the company itself. Allow for flexible schedules so that people from many different backgrounds have the freedom arrange their schedules around their beliefs and their needs, whether those are cultural, medical, or otherwise. Give staff time to get to know one another outside of their work, whether that’s team lunches, happy hours, off-site meetings, or team building activities, and be sensitive to whether or not everyone will be able to participate in those activities. Be mindful, patient, and open to conversations around diversity.

Hiring a diverse team isn’t as simple as putting a line in an employee handbook stating that inclusion is a company value. It takes work, and it’s not something that happens overnight. Luckily, it’s work that creates so much value in terms of the ideas that can be brought to the table, the perspectives that might otherwise get missed, and the great pleasure of getting to know people who have lived lives different from your own.

Get the Serverless Development Toolkit for Teams

now and get started for free. Contact one of our product experts to get started building amazing serverless applications today.

To Top