Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Serverless Cloud Integrations Meetup: The Path Forward
Similar to Serverless Cloud Integrations Meetup: The Path Forward (20)
More from AaronLieberman5
More from AaronLieberman5 (20)
Recently uploaded
Recently uploaded (20)
Serverless Cloud Integrations Meetup: The Path Forward
- 1. Serverless cloud integration requires both the right mindset and the right roadmap. Find your path forward.
- 2. 2 1. Why serverless? 2. Benefits of serverless 3. Serverless blind spots 4. Use cases for serverless 5. Quickly migrate to the cloud 6. Demo
- 3. ● Boutique consulting firm ● Specializing in integration and related technologies ● We build connections ○ Systems ○ Apps ○ Corporations ○ People 3
- 4. 4 1. API Enablement and Security 2. Big Data Movement, Preparation, and Visualization 3. Streaming Data and Real-Time Analytics 4. Process Automation, Monitoring, and Logging 5. Data Synchronization and Replication 6. Cloud and Serverless Integration
- 5. 5 84% Increased total cost of ownership Many organizations looking to move to the cloud 84% of on-premise servers are over-provisioned
- 6. 6 Stay ahead of technological trends Integration as a competitive advantage
- 7. 7
- 9. 9 Parallel Processing Cold Starts Duplicate Detection Use The Right Tool For The Job Visibility Governance
- 10. 10 • Hybrid is the new normal • Serverless could be your primary approach • But, augmentation is expected
- 11. 11
- 12. 12 Description Spikey workloads causing large bursts of traffic in your system Benefits Decrease cost, easily handle auto-scaling, use assets more efficiently
- 13. 13 Description Low volume, sporadic workloads that can run at any time Benefits Decrease cost, easily handle auto-scaling, use assets more efficiently
- 14. 14 Description Front your legacy system to handle API management Benefits Controlled, scalable, modern access points into your legacy system
- 15. 15 Description An API that needs to handle consistent, large amounts of traffic Benefits Decrease cost, easily handle auto-scaling, use assets more efficiently
- 16. 16 Description System that needs to continuously poll endpoint Benefits More complex solution due to developing serverless for always-on
- 17. 17 Description System that processes, enriches, and transforms very large files Benefits Limited scale up capacity and no out of the box transformation tool
- 18. 18 Producers and Source Systems Gateway and Abstraction Receive and Persist Route to Subscribers Process Event Target Systems
- 20. 20
- 21. 21 ROI You might be thinking… MigrationReliability Performance Security Operational Excellence
- 22. 22
- 23. 23 IncreasingCapability Sometimes “Do Nothing” is the right answerWait & Revisit Rebuild your integrations using cloud-native services (AWS Lambda, DynamoDB, etc) Custom Cloud DecreasingInitialCost Combine the strengths of iPaas with serverlessHybrid
- 24. 24 You’re Hybrid if: 1. You’ve deployed more than 1 integration platform/solution within your organization 2. You currently augment your integration solutions with services provided by AWS 3. You conduct some integrations manually (e.g. swivel chair, email, xls) 4. Your business is using lightweight citizen integrator tools (e.g. Jitterbit, Snaplogic)
- 26. 26 Inventory Processes Checkpoint Prioritize Serverless Candidates Plan/Design Implement Run the Workload Welcome to the Cloud
- 27. 27 • Iterate and fail fast • Operational in the cloud in 30 days or less
- 28. 28 • Reach out to aaron@bigcompass.com for an assessment of processes to migrate to the cloud • Contact aaron@bigcompass.com to begin your first POC in 30 days or less
- 29. 29
- 30. 30
- 31. 31
- 32. 32 Consideration iPaas Serverless License cost Implementation cost Operational cost Innovation Vendor Support Skill level Scalability
- 33. 33 • Need to extract more value from data • Speed/time to market • Scaling infrastructure faster/cheaper • Increasing cloud assets, hard to integrate from on-prem • Facing vendor issues, want to break vendor “lock-in” • Looking to explore new features, technology, integration patterns • Current on-premise environment doesn’t support a desired feature/capability • Worried about shrinking talent pool
- 34. 34 5. Inventory existing processes 6. Categorize processes 7. Identify critical timelines 8. Plan for external communication 1. Obtain stakeholder buy-in 2. Create a budget 3. Plan your team 4. Understand existing system’s architecture
- 36. 36 • Move 20%+ of your workloads in 1 year to the serverless cloud • Drastically reduce ongoing cost
- 38. We put ideas before egos. 38 Community Craftsmanship Vibrance Exploration Humility We proactively build genuine connections to strengthen our communities. We pursue elegance through passion and expertise. We celebrate the unique personalities that brighten our workday. We are driven to explore by our insatiable curiosity.
Editor's Notes
- What's out there in the industry right now? For legacy and iPaas solutions that are sitting on-prem, 84% of those on-premise servers are over-provisioned Due to the nature of on-prem servers, you are forced to over-provision your servers It's a smart move to over-provision because you want the wiggle room within those servers to be able to scale up if needed and it's very difficult to right-size your servers You don't want to come up against a point where a bottleneck is created due to the capacity of your on-premise servers You can run up against scaling bottlenecks and over-priced resources due to this increasing your total cost of ownership to maintain that system This is exactly why so many organizations are looking to move to the cloud where they don't have to be locked into the physical capacity of their data center and they can set up their foundation on a platform where they can innovate quickly, scale effortlessly, and drive their competitive advantage
- So we are here to talk about serverless and it’s just one slice of how businesses can use integration as a competitive advantage like I just talked about Serverless is hot right now! It excites a lot of people including me But outside of just being exciting... It helps power Integration as a competitive advantage You can lower cost and increase reliability If you get your deployment cycle right, you can rapidly produce flexible scalable solutions quicker than ever before Innovate quickly and create integrations as a pace faster than ever before Stay ahead of technological trends Your workloads are becoming more diverse Only increasing traffic and more systems talking to each other and becoming more unpredictable as the diversity of processes increases Opening yourself up to the serverless cloud opens you up to the rapid innovation of AWS You don’t even know how you’re going to use that in the future, but hooking into AWS allows you to take advantage of the continuing innovation and service development and features that AWS produces constantly
- Serverless is relatively new, so I want to give you the common benefits and pitfalls of serverless so that you can understand fully the value that serverless can provide, and like any technology, it has its downside, so we will discuss those and the mitigation techniques so you can deliver a serverless solution more effectively
- Here are some of the things that you can derive a ton of value out of using a serverless architecture for your integrations I want to enable you to help you understand the real-world benefits Scalability By default in AWS you can spin up to 1000 concurrent Lambdas Serverless doesn’t just scale up, it scales down too! This is a major benefit for workloads that you don’t need to keep always on, and that’s extremely common in many integration scenarios HA The wonderful thing about serverless services is that they are highly available out of the box, and with integration platforms needing to get as close these days to 100% SLAs with customers, this allows you to pass on higher SLAs to the clients who integrate with your system Just be careful of VPCs which can actually work against you for HA Security Security of serverless services in AWS is controlled primarily by IAM. Make sure your IAM roles are solid, and you will be inherently secure Of course you have to think about if you are exposing any serverless services externally, and worry about things like API security, but only in those scenarios again These first 3 benefits allow an organization to focus on development rather than worrying about implementing the right architecture for scaling, HA, and security. You still have to think about these things, but only for specific scenarios Skillsets Like I said earlier, serverless is HOT and excites a lot of people If you are looking for serverless talent, people, including us, will be excited to work on serverless projects Coding in serverless is relatively language agnostic We prefer to code in NodeJS or Java here at Big Compass, and we can code in both of those languages in AWS Lambda Other serverless services are code-less quick to create using either the AWS Console or Infrastructure as Code tools like Terraform or CloudFormation Cost Big Compass has helped our customers save over 90% in ongoing cost by moving their integration platform to the serverless cloud in AWS This is One of the main results of the scalability aspect here. First it is very cheap to run serverless services and most charge you on a pay-as-you-go model What's more, the first 1,000,000 AWS Lambda executions are free per month Second, scaling down is a huge win! When serverless is off, you are typically not getting charged for it so you don’t need an always-on solution and can take advantage of a pay-as-you-go model Innovation These benefits spur innovation Serverless allows you to focus on rapid feature development rather than the minutia of network security and VMs and virtualization etc Simply develop within a SDLC/DevOps framework, check in code, and deploy, and stay focused just on that It also allows you to build out a more rich feature set because you don’t have to worry about having the constraints of on-prem servers or if an iPaas platform has a connector to fit the need It allows the flexibility and the freedom to build what you want when you want
- The benefits of serverless can catapult a business into the stratosphere But let’s talk about some common pitfalls from what we have seen from our experience because in the real world, it’s not all a seamless dreamland of development and rapid deployments. You can easily learn these things the hard way if you are not prepared for them. Most of these pitfalls can be mitigated with a mindset shift first of all Mindset shift in that there is no infrastructure to manage, concurrency and parallel processing is king when it comes to serverless and distributed microservices need to play well together sometimes, it’s a pay as you go model, etc Cold Starts Cold starts can occur on AWS Lambda It’s a dreaded problem to have, especially when you need a rapid response from your Lambda or API Gateway Cold starts are a result of the Lambda still running on AWS’ infrastructure and when it goes to sleep for too long, it needs to load back into memory to run the function The larger the function and the more complicated the VPC networking, the worse the cold start can be So keep your functions small (after all these are microservices) and by best practice, don’t put your Lambda in a VPC unless absolutely necessary There are also pre-warming techniques you can employ that we can help you out with Governance Everyone loves microservices! As you create more serverless microservices, your governance over these can quickly expand and explode if you are not ready for it. I have seen many thousands of AWS Lambdas developed in a single AWS account, and you can imagine it can quickly get out of hand without the right governance system Planning is key here Create dashboards Monitor services Create great DevOps processes and automate using CI/CD Practice maintaining serverless hygiene Visibility The mindset shift of using many parallel processing functions and distributed microservices is a game changer for the visibility blind spot Without planning to “see” into your serverless services, it can quickly get out of hand to support. Imagine that 1000’s of Lambdas are developed and working well, but the minute you have an error, you need to find it quickly and determine what function it occurred in No integration platform is complete without good supportability, so mitigate this blind spot with a well designed, externalized, centralized logging and monitoring framework. This could be within AWS (think X-Ray, ElasticSearch, RDS, etc) This could be externalized to Splunk or other external systems Parallel processing Again, I’ll mention the mindset shift to parallel processing functions and distributed microservices Scaling on demand is a double edged sword when it comes to integrations On the one hand it allows you to process really quickly On the other hand, What this means is out of order delivery could easily become an issue in your system as well as flooding downstream systems/throttling concerns These are two very common integration patterns that can become non-trivial challenges You may need to actually throttle back a Ferrari in the cases that you need ordered delivery or have a system you are sending requests to that can’t handle heavy load It happens all the time You can use a stage for ordered delivery You can throttle back and AWS Lambda using AWS SQS queues or throttling the Lambda concurrent processing itself Duplicate Detection This blind spot bites almost everyone It’s a silent killer sometimes for businesses, because it happens rarely enough it can slip through QA testing An upstream system integrating with your system can produce a duplicate, or the actual serverless services like SQS can produce a duplicate message due to its underlying distributed architecture You can maintain a ledger of all events that have gone through the system and check events against that ledger before sending them out Make sure your ledger is easily accessible and fast, because if you process a lot of data, you could also have race conditions to worry about Use the right tool for the job There are times where you just want to try to fit a square peg into a round hole Serverless is great because you can code for virtually any use case if you want to But there are use cases where combining serverless with the right tool for the job makes sense We strongly believe in hybrid solutions here at Big Compass, and using the right technology can be a game changer for a supportable, reliable solution that users love and is easy to support We will talk about some good use cases and anti-use cases for serverless in a minute
- You might be thinking after all of that “Is serverless right for me?” Don’t worry because Organizations rarely get “there” - Hybrid is the new normal
- I see this all the time. Within your system you get a huge burst of messages or requests due to events occurring at specific points in the day Your current servers are beefed up and over-provisioned to be able to handle these large bursts. This can result in slowdowns and bottlenecks, or large costs due to a high capacity server What’s more, you are paying a lot to maintain these large bursts even when your system is sitting idle for the majority of the time! With serverless, you can invoke your processing layer from incoming messages that scale out to 1000’s of concurrently processing AWS Lambdas This allows you to process faster, handle the bursts with ease, and best of all, use your assets more efficiently. You might only have these Lambdas awake for an hour out of the day. This can drastically reduce cost for you
- Use case: low to medium volume business process that reconciles invoices when a customer makes the request Most of the day, the process is off, but on demand, we need to be able to reconcile invoices against what was actually paid Today, you probably have a server always on so you can handle this on demand request With serverless, you are taking advantage of being able to scale out AND being able to scale in The beauty of auto-scaling is it’s not just scale out, it’s scale in too With serverless, you can invoke your processing layer any time, otherwise it is dormant This allows you to use your assets more efficiently and process quickly You might only have these Lambdas awake for an hour out of the day. This can drastically reduce cost for you
- I’m seeing this use case more and more as businesses want to move to the cloud, but extend the life of their existing system in the interim The legacy system may not have internet connectivity or strict firewall rules that prevent rapid innovation, or the legacy system might be pushed to its limits Many times what I see work really well here is putting an API Gateway in front of the legacy system to handle the control, security, reliability, and customer facing endpoints that can abstract the legacy system The public serverless API can now be more flexible and open up the way in which you expose your legacy system It can also hold requests based on SLAs with clients to throttle them back so that your legacy system is not flooded So this can be used as a control access point as well Also, the cloud providers give you great API management, so now you can quickly slap on security rules, IP whitelist, provision access, monitor your API, and so on with the modern serverless API Opening yourself up to the serverless cloud opens you up to the rapid innovation of AWS You don’t even know how you’re going to use that in the future so you can take advantage
- Bringing a few of these use cases together, APIs are a great culmination of all of these use cases The use cases for APIs these days are almost limitless, but you might have a customer facing API that helps to get order information and process orders when clients make requests to your API The more you onboard clients that consume your system, the more diversity of traffic you have on this API and the more you need to prepare for reliability and scalability of the API Luckily, with Amazon API Gateway, out of the box it can handle 10,000 requests per second, and it allows for throttling if limits are exceeded for reliability purposes Behind that, API Gateway can invoke thousands of AWS Lambdas to process orders or get order information, and you don’t have to think about how these serverless services scale out Ultimately, instead of you having to scale your servers up or buy additional cores/licenses, you can use the pay-as-you-go model with a reliable, scalable API Gateway on AWS Maybe at night you don’t process as many orders, so you can save some cost Absorbing workload
- A great example of this is if you need to continuously poll an external queue like a JMS queue for messages Let’s say you need to maintain an open connection to an external JMS queue so that each time a new message lands on that queue you can process the message Essentially what you are creating in that case is a serverless solution that is always on It’s not a bad solution, it’s just that another tool might be better for the job because it can maintain an open connection to the third party system rather than putting extra logic into an AWS Lambda to code for an always on solution
- A great example of this is receiving a large manifest of the entire dump of records from a client’s system. The file comes in on FTP and is 5GB in size AWS Lambda memory maximum is 3GB so it does have limited capability to scale up, because that is not really what it is meant to handle. So you could develop a more complex architecture to split the file before processing it in Lambda, but then once you get there you don’t have an out of the box transformation utility so you would have to come up with an elegant way to make your data transformations. It’s not a bad solution, it’s just that another tool might be better for the job because tools are made to handle large files and transform files and enrich files
- Let's talk about how we implemented many of those use cases we just talked about The project we put in effect here at Big Compass is syncing SFDC data with a target system, in this case a relational database table in RDS We see this use case coming up a lot more with the rise of SFDC, and companies want to be able to use that data locked up in SFDC elsewhere in their ecosystem There is a lot going on here, but don't worry we're going to go through this diagram and dissect it Other considerations I didn’t talk about Ordered delivery Logging Error handling Mapping Bi-directional sync Configurations we store
- You might be getting really excited about the serverless cloud at this point. It is exciting! You might be thinking all of these things, and you CAN get there, but don’t turn your cloud migration to a thunderstorm
- So let’s enable your path to the serverless cloud while thinking about the best approaches to get you there We know the use cases and benefits and pitfalls at this point, so how can you most effectively enable your organization in the serverless cloud? The technology is not going to let you down It’s your plan and design and your usage of the tool that can fail
- There are a few paths that businesses can take on their way to the serverless cloud A Custom Cloud strategy is one where integrations are custom built using services provided by AWS. This strategy gives you the most capability and flexibility, but also requires the most amount of initial investment Hybrid – one great approach to enablement in the serverless cloud is to take a hybrid approach where you combine your legacy/on-prem/iPaas solution with serverless This can be great because you can combine the strengths of each approach, and start to dissect your current system for the best use cases to move iteratively to the cloud, and choose the right candidates to move to the cloud Wait and Revisit - Sometimes “Do Nothing” is the right answer. In cases where there are multiple drivers in conflict and the path is unclear, sometimes the best option is to analyze your existing infrastructure and integrations and begin planning for the future but delay execution until the business drivers are clearer.
- No matter your path, you are going to see some form of hybrid along the way Hybrid is almost a given You ARE going to be hybrid You are hybrid if you use an IdP with your API management You are hybrid if you combine MuleSoft with AWS all deployed to the cloud You are hybrid if you are using a transformation tool that is different from your routing logic You are hybrid if you are manually send email once a week to collect payments from a customer Regardless of your approach, at some point you will need to support more than 1 technology to enable your integrations, so planning for this is very important
- The quickest and best way to get to the serverless cloud is through decomposing your legacy/on-prem/iPaas into the components that are the best candidates to move to the cloud That is why your planning phase is so critical where you categorize your system based on 2 dimensions System components Processes Your bridge to the cloud is iterative success through the hybrid approach This is exactly what Big Compass can help you with by bringing our integration knowledge combined with the cloud knowledge to help you identify great candidates that can work with the serverless cloud
- How do we accomplish this? It’s not some magic trick or marketing scheme – it’s based on experience We want you to be successful if you choose to take this path because it has been a tried and true methodology that we would recommend and one that we use We have 5 phases Inventory processes Checkpoint after phase 1 where if we don’t find serverless candidates it’s free Prioritize serverless candidates Design for the serverless cloud working with your system, adopting the serverless cloud, whether you need customer communication or not You can use prior knowledge here to an extent, but sooner rather than later you want to involve AWS experts like we have here at Big Compass to ensure that your serverless architecture is sound Then you can get to implementation Again people are excited to work on serverless, but you'll want to involve people with know-how so that the blind spots don't rear their ugly head Deploy and run the workload Welcome to the cloud! Ultimately you can take this on -and we want you to be successful because we're excited about the serverless cloud! And you can also call us at Big Compass to take you through the planning, design, and implementation of your serverless adoption Unless you are building a new application, migrating to the serverless cloud is a cyclical process that might look like a standard SDLC, but it’s more nuanced than that Plan We just talked about the planning phase, and I can’t emphasize enough how crucial the planning phase is This is where stakeholders will buy in, where you would identify good candidates for the serverless cloud, create a timeline, plan a team, and much more. This is where you would make certain that you aren’t fitting a square peg into a round hole, and you might even get a temporary POC approved to ensure that We could come in and rip out everything, but that’s usually not the best path Let’s dive into planning because it is so important Once you have identified the serverless integration path you want to take, you can start planning what your serverless integrations will look like It’s important to take a step back and make sure that you are aligned with the business and can convince stakeholders to sink CapEx spend into something that will result in reduced OpEx spend in the future From there you can, Create a budget with the stakeholders Plan your team Could be an internal team Could be an external team Big Compass is happy to help you with this Understand and inventory the existing system I have run across countless use cases where this effort is nuanced due to lack of documentation, turnover, complexity, you name it… So this becomes really important to get a handle on what your current system is doing and processing You can break this down two ways First is what components of your system are there Second is what types of processes does your system process Categorize processes and identify good candidates for serverless Big Compass will take an unbiased approach based on our experience and knowledge of what good candidates for serverless are Identify critical timelines For example, a license renewal date is coming up in 6 months Plan to communicate the migration to customers/clients if external endpoints are being moved Design It’s possible here to use some expertise from your legacy system’s architecture However, as we just talked about the serverless cloud is a mindset shift, so you will want to involve cloud experts like we have here at Big Compass sooner rather than later to architect how the processes will work in the serverless cloud You can also think about DevOps, SDLC, and CI/CD here and define your standards Implement Skillsets are flexible in the cloud, but again at some point you will want a team with expertise of how the serverless services interact with one another But otherwise this is where you can set up sprints and move quickly! Testing You might even have the same regression tests as before! Deployment If you are trying to move quickly, deployment might be manual at first If you took the time to implement CI/CD, use your DevOps processes defined in your design phase to automatically deploy your serverless environment with something like AWS CodePipeline or the Serverless framework, which is what we like here at Big Compass
- Ultimately, you want to adopt the serverless cloud quickly for the maximum ROI you can achieve Failing fast is a great approach for this This type of approach will allow your business to test the waters with minimal risk So at Big Compass we have a serverless template that acts as an accelerator that can get you up and running with serverless services in AWS quickly And we come in with integration expertise, and mitigation techniques for the serverless pitfalls And from all of that, we can get you operational in the serverless cloud in 30 days or less If there is a process that is a no-brainer to move to the serverless cloud or that you have battled with for a long time that’s causing a bottleneck in your system, these are great candidates to prove your serverless approach on and prove it quickly Overall, we believe that at bare minimum 20%+ of your portfolio can benefit from a serverless cloud adoption We would encourage you to look through your portfolio and find those candidates, and we can also help you with that If your organization doesn’t have resources laying around… With this iterative approach, you can adopt the serverless cloud quickly and at minimal risk. It allows you time to get used to supporting the serverless cloud in AWS and even gives you an option to back down if serverless is not for you We’re so confident that so many organizations are over-provisioned, and we will identify the processes where you can recoup the cost of your investment within a year We can come in, help you quickly categorize your system and processes running through your system, and identify 20% of the workloads to move to the serverless cloud in under a year Of course, the ROI depends on complexity and everyone’s unique use cases, where we might be able to move 20% of your workloads in 1 month depending on complexity, or 80% of your system to the cloud in under a year, The point is the more aggressive you are, the faster you will realize an ROI On average, what this results in is a ROI within 3 years, and the more aggressive you are the quicker you would see the ROI
- So of course the serverless cloud is something we here at Big Compass are very passionate about It allows us to bring innovation to integration and allows businesses to be highly competitive in your respective industries So don’t hesitate to reach out to us We don’t have to engage in any one particular way If you need us to coach you through this we are happy to do that If you need to strategize before making the leap, we can do that too Or anything in between Don’t hesitate to reach out
- When you consider a build vs. buy decision, these are the factors that can go into that
- Hybrid as a path to get there
- We could come in and rip out everything, but that’s usually not the best path Let’s dive into planning because it is so important Once you have identified the serverless integration path you want to take, you can start planning what your serverless integrations will look like It’s important to take a step back and make sure that you are aligned with the business and can convince stakeholders to sink CapEx spend into something that will result in reduced OpEx spend in the future From there you can, Create a budget with the stakeholders Plan your team Could be an internal team Could be an external team Big Compass is happy to help you with this Understand and inventory the existing system I have run across countless use cases where this effort is nuanced due to lack of documentation, turnover, complexity, you name it… So this becomes really important to get a handle on what your current system is doing and processing You can break this down two ways First is what components of your system are there Second is what types of processes does your system process Categorize processes and identify good candidates for serverless Big Compass will take an unbiased approach based on our experience and knowledge of what good candidates for serverless are Identify critical timelines For example, a license renewal date is coming up in 6 months Plan to communicate the migration to customers/clients if external endpoints are being moved
- Unless you are building a new application, migrating to the serverless cloud is a cyclical process that might look like a standard SDLC, but it’s more nuanced than that Plan We just talked about the planning phase, and I can’t emphasize enough how crucial the planning phase is This is where stakeholders will buy in, where you would identify good candidates for the serverless cloud, create a timeline, plan a team, and much more. This is where you would make certain that you aren’t fitting a square peg into a round hole, and you might even get a temporary POC approved to ensure that Design It’s possible here to use some expertise from your legacy system’s architecture However, as we just talked about the serverless cloud is a mindset shift, so you will want to involve cloud experts like we have here at Big Compass sooner rather than later to architect how the processes will work in the serverless cloud You can also think about DevOps, SDLC, and CI/CD here and define your standards Implement Skillsets are flexible in the cloud, but again at some point you will want a team with expertise of how the serverless services interact with one another But otherwise this is where you can set up sprints and move quickly! Testing You might even have the same regression tests as before! Deployment If you are trying to move quickly, deployment might be manual at first If you took the time to implement CI/CD, use your DevOps processes defined in your design phase to automatically deploy your serverless environment with something like AWS CodePipeline or the Serverless framework, which is what we like here at Big Compass
- We believe that 20%+ of your portfolio can benefit from a serverless cloud adoption We would encourage you to look through your portfolio and find those candidates, and we can also help you with that We’re so confident that so many organizations are over-provisioned, and we will identify the processes where you can recoup the cost of your investment within a year
- Your ROI will be determined by how aggressive you are with your cloud trajectory A typical migration will look like this where you have you migration period, TCO, and cost optimization phases