Replies: 3 comments 2 replies
-
It was great to have Tod and Michael walk through this vision at re:Invent. Does an EKS rather than a ECS deployment figure in the roadmap? I am sure you are aware of https://github.com/aws-samples/aws-saas-factory-eks-reference-architecture which is doing some of the same things as SaaS Boost, but is obviously independent. Does moving to using CDK mean that we will be able to use Terraform through https://github.com/hashicorp/terraform-cdk ? Sherman |
Beta Was this translation helpful? Give feedback.
-
Does anyone have a link to the video of Tod and Michael going over SaaS Boost vNext at re:Invent 2021? I found the slides but can't find the video anywhere. For anyone who finds this post, slides are here: SaaS Boost vNext Additionally, will there be a migration plan from v1 to this updated version? From the material it looks like there will be breaking changes. |
Beta Was this translation helpful? Give feedback.
-
@brtrvn I am on the main branch, I just pulled the code last week. Does this version support the below options called out in the roadmap? I am looking for a pool model, I have tried the latest version but I see only the silo model supported. |
Beta Was this translation helpful? Give feedback.
-
Vision & Roadmap
It is important to us to think in public as an open source solution and engage the community of users and contributors. This open letter to the SaaS Boost community is one way to reflect on the purpose and goals of SaaS Boost as well as the technical challenges faced while building the initial version of SaaS Boost and how those experiences are shaping our strategy to continually improve the solution and the value it provides.
Origins
Our original goal for SaaS Boost was to create an easy-to-use solution that would accelerate the move from a traditional software delivery model to a hosted subscription based – or SaaS – delivery model. Our focus was on minimizing the changes to your software solutions in order to leverage SaaS Boost. We feel the value of presenting your software solution to your customers in a SaaS model quickly outweighs some of the inefficiencies of how SaaS Boost provisions the infrastructure to make that business change possible. We provided SaaS Boost as a starting point of your business's SaaS journey.
We achieved those original goals. In the first 6 months of public availability, the SaaS Boost repository has been cloned over 1,500 times by builders looking for best practices and tooling to accelerate their solutions. SaaS Boost supports a friendly user interface to configure how you'd like to provision your application workload. Both Linux and Windows based workloads are supported as well as a rich selection of relational databases and network file systems. Tenant onboarding is completely automated and supports continuous deployment of your application. Operational insights are visualized across all tenants and we even have some basic integration with a billing provider. All of this is happening in a secure, highly available architecture that is in your control.
Learnings
We hear our community and contributors asking for a more flexible environment that supports modern architectures and is easier to customize. We know getting Windows based workloads – especially IIS – to work well in containers is difficult. We know there are builders who want to leverage more functionality from our shared services even if that requires modifying their application to do so.
We have added features to temporarily suspend workloads to save on costs during development, shown you how to extend the onboarding experience to include new resource types like noSQL databases, and we've added a turn-key Windows based sample application to give you a head start on building a container for your IIS web applications.
We are actively working on version 2 (#25) of SaaS Boost to address the most requested feature of being able to run more than one container per tenant environment. This multi-container support will allow you to describe an application workload that has a few pieces of compute working together all the way to describing a complex micro services based application.
While version 2 is an important milestone of functionality for SaaS Boost, it is not the complete vision we have for the future.
Vision
This is our vision for the future of SaaS Boost:
SaaS Boost supports simple architectures, like the monolithic applications it supports today, as easily as it supports complex architectures like a distributed micro services base solution. You will be able to define whether you want your infrastructure to be securely shared by your tenants or isolated in silos. You will be able to choose what kind of compute you want to run your solution in so that you can leverage serverless, different container management systems, virtual instances or any combo thereof to maximize the benefits of a cloud based architecture.
SaaS Boost is more builder friendly. Yes, you can customize the tenant provisioning experience today by modifying CloudFormation templates and introducing new properties to the AppConfig class, but it is not as approachable to software builders as a programmatic API solution would be.
SaaS Boost shared services are leading examples of best practices, reduce your undifferentiated heavy lifting, and provide operational value. These shared services that support SaaS workloads will be documented and mature in their design and deployment system so that cloud native SaaS builders do not have to repeat common patterns that are better provided by a framework.
SaaS Boost shared services are designed for integration so that 3rd party solutions can be adopted to further enrich the implementation and support specific use cases.
Roadmap
We have a proposed strategy to reach our vision of
Splitting Application Management from the Control Plane
In order to create a solution with the flexibility to describe, provision, and maintain the complex modern architectures of SaaS solutions, we want to extract that functionality from the shared SaaS services of the control plane into what we're calling an application plane. This tooling will be responsible for defining the layout of your solution – what kind of services, front end, databases, file systems, object storage, and other infrastructure components make up your application – as well as the multi-tenant isolation model you want to provision each layer into, be it siloed or pooled.
Builder Friendly Customizations
In order to make the solution more builder friendly when it comes to customizing and integrating, we want to move the infrastructure as code (IaC) portion of the application plane to the CloudFormation Development Kit (CDK). By leveraging CDK we gain a developer-first experience that gives us the tools to build complicated CloudFormation stacks complete with control structures (if/then and loops) evaluated at runtime.
SaaS Control Plane
In order to build the leading shared services SaaS Control Plane, we want to create new services such as Identity for application user management and authentication, Tiering to describe how you package your offering to your customers, as well as continuing to evolve the existing services SaaS Boost offers today.
Extensibility through Integration
In order to simplify the integration of 3rd party solutions into our Control Plane, we want to rework the billing and analytics services to present a coherent API to your application while using software engineering best practices on the back end to support implementation of that API with different 3rd party providers.
Beta Was this translation helpful? Give feedback.
All reactions