From Aspiration to Action: Where to Begin Your Serverless Cloud Adoption
The cloud is no longer a new, shiny object. Cloud technology offers tremendous value to companies, regardless of size, revenue, or purpose.
That’s why so many organizations are considering a move to the cloud now. Some, looking for the ultimate scale and flexibility, are going a step further and looking to realize the benefits of the serverless cloud.
There are a multitude of use cases for migration or adoption of the serverless cloud. You could be considering a move from an iPaaS to a serverless solution. Moving from a legacy system to serverless is also a common use case, as is deconstructing a monolithic system already in the cloud into many distributed serverless components.
Just as there are a multitude of solution types, there are a bunch of goals associated with a move like this. You could be taking advantage of serverless to realize budget savings, improve scalability, simplify the management of legacy systems, extend the life of a legacy system, or some other reason.
But so often, the same organization that is looking to modernize doesn’t know where to start. A migration to the cloud or to serverless can seem overwhelming and sometimes even impossible.
This article is the first in a series intended to help you navigate through these complexities toward whatever your cloud migration objective may be. This series is intended for the leaders and architects responsible for making well-informed decisions around moving to the cloud, and more specifically, about moving to serverless so that you can do so with confidence and clarity.
You Know You’re a Candidate to Move to the Cloud When…
It’s all well and good to talk about the theoretical advantages of moving to the cloud and to serverless. But, from a practical standpoint, how do you know when your organization is ready to move?
This point looks different to everyone. It’s no longer simply about breaking up a monolith, and legacy is a sliding scale - what may be legacy to you looks like new technology to someone else. When evaluating a move, there are a few key inflection points:
- You’ve identified that your legacy system has become too difficult to support
- You have a large monolith that is pushing the limits of your server’s capacity
- Your iPaaS is not able to scale with the business demands
- The legacy or monolithic system you have is fragile and keeps breaking
- Digital transformation and IT innovation are drivers for your organization
- You use Integration as a Competitive Advantage (IaaCA) in your organization
Do these look familiar? Then it's time to get started.
What to Expect from Serverless Adoption
Getting started, however, takes a certain mindset. This is an entirely new paradigm for most companies, and you must be prepared for what your first adoption of serverless may look like. The list below might seem a little daunting, but by being prepared for the challenges, you’ll be able to set the right expectations which will lead to success.
Learn from Failure
No one should go into serverless implementations thinking it won’t be challenging. In addition to the common pitfalls, it’s important to remember that you’re rolling your own code on AWS Lambda for the heavy lifting of what you’ll be doing, which can bring its own challenges.
The concurrency and scale paradigm shift may surprise you with rare issues cropping up such as duplicate Lambda invocations or unordered delivery. Deployments can involve many services and can, themselves, be difficult.
The takeaway here is that everyone makes mistakes with serverless, but getting to the right place means using those mistakes as a learning tool. Dial-in your serverless processes over time, and don’t expect to get it right the first time out of the gate.
Of course, mistakes and missteps can lead to frustration. For instance, it can be frustrating when some of the errors you experience only occur at high traffic volumes. How were you supposed to see that coming?
Give yourself - and your teams - some grace and roll with the punches, or prepare for the common pitfalls of serverless mentioned above. You’ll learn, you’ll tweak, and you’ll learn some more. In the end, it’s worth it.
Slow Time to Adopt
It doesn’t help with the frustration that it can take a significant amount of time to ramp up when getting started with serverless. It’s an utterly different model, with different architecture. Compounding this, you may even be moving to a new cloud provider, like AWS, that supports serverless and have a new system and setup that you need to become familiar with.
Building on the last two pieces of advice, be patient, and use serverless DevOps best practices to speed up, govern, and scale your operations. You will get better over time.
Lack of Knowledge (at first)
If you’re expecting to jump into serverless and master it immediately, here’s your wake-up call. AWS alone has more than 175 services. It’s too much to grasp when you get started. You can learn about the core serverless services to start.
Don’t let this stop you. Hands-on experience will help you get familiar with the services the more you work with them.
Accept it - you’re going to be hybrid along the way.
The reality is, making a giant leap isn’t even the best path to take—plan for a hybrid solution where you combine your legacy/iPaaS system and serverless solutions to get started.
Don’t try and boil the ocean - it won’t get you where you need to be.
For some of us, this can be the hardest part. If you get stuck or feel overwhelmed, reach out for help. Take a step back and read up on the subject you’re struggling with, or talk to experts at Big Compass who have already been through the process. Our knowledge may give you a whole new perspective.
Change is Coming
It seems obvious to say that things will be different. However, prepare for these shifts in your organization.
A move to serverless pairs well with an innovation mindset. The flexibility and scale of serverless allows for limitless opportunities to be built on the technology. Once you nail down your serverless DevOps best practices to govern your serverless services, you can develop and deploy rapidly, as well as realize an abundance of other benefits.
This also means a significant shift in architecture - both practically and philosophically. Serverless will offer nearly unlimited concurrency. Architect your system to take advantage of concurrently running functions.
You’ll be leveraging concise microservices on AWS Lambda, and you will likely build many of them, so, as a result, prepare to have a sizeable serverless footprint. This will be different from the legacy systems or architecture you used to support your monolithic applications because you have to manage many different components rather than a single monolith.
If you aren’t using serverless already, you’ll need to make the skillset switch to something like AWS Lambda. This involves writing code in NodeJS, Java, Python, or a few other languages. It’s also a good idea to have your team ramp up on AWS skills and best practices in general.
You’ll be switching to using AWS Identity Access Management (IAM) groups, roles, and policies to restrict access to your resources. Of course, if you aren’t deploying in VPCs, network security falls by the wayside, increasing development speed by allowing developers to focus on building business logic.
If you aren’t already using Agile, now’s the time - and it’s not really an option. Agile is very necessary with serverless. A waterfall approach will leave you trying to manage and deploy 10s or 100s of serverless microservices at once. Agile will allow you to bite off small chunks, which is crucial to your serverless adoption.
Sure, the cost is one of the significant benefits everyone points to with the cloud in general and with serverless specifically. However, as with any implementation, you’re going to have implementation (CapEx) costs upfront. Over time, your ongoing costs (OpEx) will drastically decrease with pay-as-you-go. You can calculate your ROI by taking into account the implementation cost and ongoing cost versus the ongoing cost of your legacy system.
Get ready for some changes to your DevOps with serverless. You’ll likely be managing a large footprint of serverless services, and your DevOps processes need to be designed to handle that. Use Infrastructure as Code (IaC) as much as possible.
Take Action - Begin Your Move to the Serverless Cloud
Getting started on the serverless cloud adoption path involves a few discovery steps. Follow these steps to begin your serverless journey.
- Inventory the components of your existing system
- Understand each of those pieces
- Categorize each component of your legacy system using Domain-Driven Design (DDD)
- Identify suitable candidates from the list for serverless that are ideally low risk and relatively simple (remember - you will be hybrid, at least for a while)
The result will be a categorized inventory in a spreadsheet or table of the legacy system components to identify the top serverless candidates.
This begins your serverless adoption. It all begins with a few simple steps to get started on your journey. If you’re struggling with coming up with this list, remember the rule from above - ask for help. Big Compass has tons of experience with precisely this kind of discovery process, leading to a move to serverless.
This is the beginning of your move to the serverless cloud, and it’s not a small shift. The goal of serverless is to enable your organization, not overwhelm it. To do it well, begin with simple steps and prepare your organization for the coming changes. Take the move in bite-sized chunks, and don’t expect to move everything at once. If you need help - ask. Big Compass would be happy to discuss how to make this process go as smoothly as possible.
In the next blog in this series, we will discuss what to do after you have completed your inventory identifying the components of your system. Keep reading to discover how to move from the planning stage to the crucial (and fun) part – taking action and adopting the serverless cloud.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents