There has always been a truth that was detached from any technology choices: If you spend more time on what customers see and interact with the result will be faster iteration and more success.

Almost daily, it feels like something new comes along that (supposedly) shakes the way we are doing development through a new package, programming language, construct, etc.

In reality, these are mostly irrelevant.

They are irrelevant because the only thing that matters is what makes customers happy and increases the usage and adoption of our products.

Building a business in 2023 is both easier and harder than ever before.

It’s easier because we have access to unlimited information, tutorials, etc, to accelerate the building of our business. However, an ocean of choices also means an ocean of choices.

What we choose to spend time on has a direct impact on the expected success we may see with our businesses.

This is more clear than ever in the tech world when building software that customers will interact with in a globally competitive space where TTM (time-to-market) either sets you up for success or sets you up for failure.

The mistake I see a lot of companies making in the tech space is choosing the wrong path early on that was sold to them as the holy grail to development, and then ultimately they are left adrift trying to paddle a wood plank in an ocean of information with no compass and no land in sight.

You may be wondering: “How is any of this related to CloudGTO, a platform that helps developers build serverless applications on AWS?”

Well first, let me introduce myself, then let’s dive into a high level of CloudGTO, and talk about why it was made, how it works, and what it’s supposed to solve.

My Background

My name is Ryan Jones. My career with AWS, Serverless, NodeJS, Python, etc, really started in the Innovation Engineering Department at Nike WHQ in Oregon, where I was helping build IaC for innovative products that weren’t guaranteed to see daylight.

Throughout my time at Nike, I was seeking out ways to do freelancing. One of those was building a Job Fair chatbot for Portland Community College, which leveraged an entirely serverless architecture on AWS, NLP (Natural Language Processing), and other common services.

The success here led me to break away from Nike to join a serverless consulting company, where I was the lead consultant before eventually starting a company called Serverless Guru.

Serverless Guru swag

The early days of Serverless Guru consisted of long hours and balancing multiple projects helping do a mix of serverless training, development, and overall consulting. In the background, learning about all the other aspects of running a business.

At this time I was also writing articles about serverless, speaking at local events, hosting meetups, making YT videos / streaming about AWS, and studying for AWS certifications.

I was in full belief that serverless was the future going back to early 2017, long before Serverless Guru was founded or Nike ever seemed like a reality. As my experience with serverless grew, my belief kept growing, and it’s stronger than ever before 5+ years later.

Serverless allowed me, a somewhat fresh developer, to compete against much more experienced developers and perform at a level that made me unique in the marketplace. It was my launching pad, and I’ve never looked backward.

At a high level, what I’m calling serverless is utilizing fully managed services that are pay-per-use and scale horizontally + vertically on AWS. From 2017 to now, serverless has rapidly matured. As a result, Serverless Guru has gone from a company of 1 to a combined team of more than 40+ Serverless Gurus globally with clients like AirCanada and Hyatt Hotels.

Only 20% on what truly matters

While this growth was taking place, a pattern continued to form. For example, when we would be asked to build a serverless API, it was almost identical each time to other requests to build serverless APIs. If I broke this into a percentage, 80% was similar, and 20% was not. Typically 80% was the IaC (infrastructure-as-code) which is basically general purpose legos that set you up for the 20%. The 20% was typically the customer-specific application code.

Another way of looking at this breakdown. The 80% was all the steps to build a house aside from the interior/exterior decoration. The 20% was what the person in the house would see and interact with, what they would enjoy, and what would bring life to an otherwise lifeless structure.

Building blocks of CloudGTO

To understand CloudGTO, we must dive into a concept we often reference as developers, DRY (Don’t Repeat Yourself). DRY coding is the best kind of coding as it ensures we code things in a way that is able to scale, simple to understand, and, most important, not just a copy/pasta over and over or an if/else tree hell.

Also, to understand CloudGTO, we have to dive into IaC. IaC is a way of building software applications in a way that mirrors cooking recipes. You write down all the ingredients, measurements, timing, and then hit bake. Out comes a cake. Then when you want another cake, you just hit bake again, and bang, another cake. Modify one ingredient in that list, hit bake, and bang, another cake. It’s consistent, easy to update, lays out exactly what will happen, and it’s repeatable.

CloudGTO helps developers build the 80% of general-purpose legos. It helps simplify the building of the IaC in a way that is optimized for best practices and has those baked in by default. It’s an abstraction over the most widely adopted IaC framework for serverless, called Serverless Framework (serverless.com). It’s designed to help you rapidly speed up the 80% so you can jump straight into the 20% that is specific to you.

CloudGTO Service Creation Flow

Through the CloudGTO platform you:

1. Define what your use-case is e.g. REST API or GraphQL API
2. Select a quickstart blueprint that auto-creates some resources to speed up the process further
3. Add any additional resources like SQS, SNS, S3, etc.
4. Link resources to Lambda triggers where necessary
5. Create HTTP routes for the API and link those to use JWT authentication, connect to a Lambda
6. Review everything in one comprehensive high-level view
7. Press build, and a few seconds later, look at the code generated inside the platform
8. Download locally and deploy to your AWS account

In minutes you can go from idea to successful deployment. You can see all the IaC, all the interconnections, and all the best practices baked in.

Preview files and architecture generated

This is important because through our beta testing, we’ve received feedback from experienced developers and founders of serverless companies about the actual real developer speed increases CloudGTO provides.

How long do you think it would have taken someone with 0-1 years of serverless experience to rebuild the same architecture via IaC with Serverless Framework without CloudGTO?Probably a couple weeks

• Tom Kowalski, 8yr serverless veteran

From multiple days or weeks to minutes. Think about that for a second. Take a developer rate, multiply it by 8hrs/day, and out comes a number that represents the cost savings per new service created using CloudGTO. As the complexity goes up in the service, the cost savings and time savings also go up.

However, that’s only one calculation, what is the cost and time savings of consistency and standardization?

From my experience, without consistency and standardization baked in by default, a large amount of time will be spent on meetings, PR reviews, etc, trying to track down divergence and correct it.

What is the cost of flow being broken? Flow is a crucial aspect of developer velocity because when we context switch to fix bugs, we become less efficient, and performant. The less flow we experience directly translates into less forward momentum for the business.

We want our developers to be consistent. We want our developers to be in flow. We want our developers to spend the majority of their time on the 20% that is different. We want our developers to spend time on features that customers see, interact with, and love.

That is the story behind CloudGTO.

In it’s current form, if you build serverless applications, it will rapidly accelerate your work. If you’re a company that wants to focus more on the product, it will rapidly accelerate those aspirations. If you’re building a startup and can’t afford to burn time trying to paddle through the ocean, it will rapidly get you where you want to go.

It’s not a magic pill. It’s just the collective brain power of years of building world-class production serverless applications on AWS for customers globally, condensed into a product.

Quotes from Beta Testers

Having seen many bootstrap repos or starter projects that purport to give an IaC foundation or quick jump into writing code and not worrying about AWS, I can positively say that no developer without a plentitude of experience could even find documentation on where to start before CloudGTO handed them a best practices configuration. Time to MVP would be dramatically cut using CloudGTO - from hours and days to maybe minutes or hours. I'm very excited to see where this goes and how it can help me and my team!

• Dallas Slaughter, 5+ year serverless veteran

CloudGTO takes care of a lot of the boilerplate which makes it easy to hit the ground running with serverless. As the team behind it has a lot of experience with serverless, you get the best practices of IaC right out of the box.

• Taavi Rehemagi, 7+ year serverless veteran and CEO of Dashbird

If you’re interested in trying CloudGTO, I would recommend you visit cloudgto.com, where you can sign up for our beta program and find out if CloudGTO could save you hundreds or thousands of dollars per service per developer and shift your focus away from everything else, but the product.