AWS Partner Network (APN) Blog
Don’t Miss the AWS Partner Summit in Singapore on April 29th
The AWS Summit – Singapore is fast approaching, and the day after the Summit represents the start of an exclusive event for APN Partners, the AWS Partner Summit – Singapore!
What can you expect at the AWS Partner Summit – Singapore?
The AWS Partner Summit – Singapore will be held on Friday, April 29th, the day after the AWS Summit – Singapore. This event is free, and is exclusive to AWS Partner Network (APN) members. It’s a great opportunity to hear from the AWS leadership about the future of the cloud and the value of working as an APN Partner. The event also affords you the chance to connect with fellow APN Partners and AWS staff.
Agenda
Partner Summit – Singapore registration starts at 8:00 am, and the opening keynote will kick off at 9 am. The rest of the schedule is as follows:
9:50 am – 10:30 am: Succeeding with AWS by Delivering High Value Services
10:30 am – 11:00 am: Break
11:00 am – 11:40 am: Building a Big Data and Analytics Practice – Partner Opportunities with AWS
11:40 am – 12:15 pm: Closing Keynote: The New World of IT
12:15 – 12:30 pm: Partner Awards
12:30 pm – 1:30 pm: Lunch
Speakers
The speakers at this year’s Partner Summit include:
Dr. Werner Vogels, Chief Technology Officer, Amazon.com
Terry Wise, Vice President, Channels & Alliances, AWS Worldwide Partner Ecosystem
Craig Stires, Head of Big Data and Analytics, APAC, Amazon Web Services
Markku Lepistö, Principal Technology Evangelist, APAC, Amazon Web Services
To register for the Partner Summit – Singapore, click here.
AWS Marketplace Announces New AWS Marketplace Metering Service For 3rd Party Sellers
Kamlesh Talreja is the Director of Engineering for AWS Marketplace.
Do you sell on AWS Marketplace?
If so, you’re likely familiar with the benefits your customers get from AWS Marketplace, including pay-as-you-go pricing and simple deployment options. AWS Marketplace is our fast growing online store that helps customers discover, buy, and deploy software that runs on AWS. It’s an increasingly influential channel for ISVs, AWS Channel Resellers, and Systems Integrators (SIs) to offer software products and services to customers in AWS Marketplace’s multi-region footprint. Amazon EC2 hours deployed by AWS Marketplace listed products in 2015 grew to a record 143 million EC2 hours per month.
At AWS, we’re always adding new features based on the requests of our customers and software vendors. When we launched in April 2012, sellers could only list products on AWS Marketplace using hourly and monthly pricing. In 2014, the addition of new features allowed sellers to price their products under an additional annual pricing model. Even with these options, sellers couldn’t list certain products on AWS Marketplace and customers had to buy products in ways that, in some cases, didn’t match the value they received. Today, the AWS Marketplace team is happy to announce a software metering service that supports new pricing dimensions such as users, hosts, and data. After a seller integrates their product with AWS Marketplace Metering Service, that product will emit an hourly record capturing the usage of any single pricing dimension. Buyers can then easily subscribe to software priced by this new dimension on the AWS Marketplace website and only pay for what they use.
What does this mean for customers?
Many types of software provide value to customers based on the number of hosts the software manages, the amount of data it processes, or the number of users it allows. By permitting AWS Marketplace sellers to list products priced along these dimensions, customers who buy software on AWS Marketplace can now easily scale usage up and down on products that integrate with the new AWS Marketplace Metering Service. This better matches how customers want to pay and better matches the value they derive from software they buy on AWS Marketplace.
What does this mean for APN Partners who sell, or want to sell, on AWS Marketplace?
If you’re a software vendor selling on AWS Marketplace, chances are you are one of the over 100 sellers who have told us that you’d like the option to price your software on dimensions that reflect the value you deliver to your customers. Using the new AWS Marketplace Metering Service, you can now charge along the top dimensions. This additional pricing flexibility opens the door for you to both modify your current product offering to use this feature, AND to bring new solutions to AWS Marketplace, and enables you to meet your customers’ needs in a seamless and scalable fashion.
“We are winning more buyers because they have the flexibility to buy our software in the way that meets their needs,” said Partha Panda, VP of Global Channel and Strategic Alliance, at Trend Micro. “We were able to quickly integrate with the AWS Marketplace Metering Service and begin selling our Deep Security Manager on a per host protected model. Our customers are now charged in the way that is aligned with the way AWS charges their customers, and they pay in the way they want, on their existing AWS bill.”
Other sellers taking advantage of flexible consumption pricing include Aspera, Chef, and SoftNAS.
When are products that support these new pricing dimensions available?
These products are available now. You can find all of them by searching AWS Marketplace. Visit https://aws.amazon.com/marketplace to get started.
How do I get started?
To register your product to use the new AWS Marketplace Metering Service, take the following steps:
- If you’re a new seller on AWS Marketplace, register by visiting AWS Marketplace, or go directly to: https://aws.amazon.com/marketplace/management/register/.
- Next, you will have to register your product for a new type of usage dimension. On the form, indicate the dimension you want to meter.
- Next, you’ll be able to acquire the specific productCode and usageDimension. When you register your product, you can download a SDK to help you format your metering records. You will have the option of downloading a SDK for any of the languages the AWS SDK supports.
To learn more about selling software on any of the new consumption dimensions, including the steps to modify your product to use the AWS Marketplace Metering Service, visit the AWS Marketplace Seller Portal.
Don’t Miss the AWS Partner Summit in Sydney on April 26th
Are you an APN Partner based in Australia? Are you a global company looking to connect with other APN Partners with a regional presence? If you’ve answered yes to one (or both) of these questions, then don’t miss the opportunity to join us in Sydney for the AWS Partner Summit on April 26th!
What can you expect at the AWS Partner Summit – Sydney?
The 4th annual AWS Partner Summit – Sydney will be held on Tuesday, April 26th, the day before the AWS Summit – Sydney. This event is free, and is exclusive to AWS Partner Network (APN) members. It’s a great opportunity to hear from the AWS leadership about the future of the cloud and the value of working as an APN Partner. The event also affords you the chance to connect with fellow APN Partners and AWS staff.
Sessions
The Partner Summit will kick off at 13:00 with the APN Keynote delivered by Terry Wise, VP, Channels & Alliances, AWS. Following the keynote, there will be three session tracks offered:
15:00 – 15:45
- Helping Large Organisations Transform Their Business Using AWS
- Building a Thriving Consulting Services Business with AWS
- Microsoft Workloads on AWS: Best Practices and Patterns for Architecture, Migrations, and Licensing
15:50 – 16:35
- Realising the Benefits of Cloud: Cloud Migration & Cloud Adoption Framework
- Getting Started with AWS: Partner Programs, Training and Enablement
- Partner Managed Services on AWS
16:40 – 17:25
- Selling with AWS – Understanding How to Leverage the AWS Sales Methodology and Partner Best Practices
- Expanding Your Cloud Business with AWS Marketplace
- Building a Big Data Practice on AWS
Networking
Hoping to build connections with other firms in the AWS Partner ecosystem? With time dedicated to networking from 17:40 – 18:30, take advantage of your opportunity to get to know other APN Partners, and learn about the services and solutions being offered and built on AWS that your firm may be able to leverage.
Training – Register Before April 1st for an Early Bird Discount on AWS Bootcamps
We also want to ensure you’re aware of the training opportunities available to you on April 26th.
There are five full-day training bootcamps happening, and the bootcamps have the following pricing structure:
AWS Certified Professionals – $400AUD
Early Bird Discount (from 1st March to 1st April) – $500AUD
Standard Price – $600AUD
The AWS Summit – April 27th and 28th
Last but certainly not least, the two-day AWS Summit – Sydney starts the day after the Partner Summit. There are a wealth of sessions and networking opportunities at the main AWS Summit; don’t miss your opportunity to connect with customers from across the region! Learn all about the AWS Summit – Sydney here.
“Friends Don’t Let Friends Build Data Centers”
Reflections on the two-year anniversary of Infor going all-in with AWS
Two short years ago at the AWS 2014 San Francisco Summit, Infor CEO Charles Phillips stated, “friends don’t let friends build data centers’’ and announced that Infor, a leading provider of industry-specific ERP solutions, was taking a cloud-first development approach and going “all-in” with AWS. Building on AWS has enabled Infor to concentrate on its core competency of developing innovative industry-specific applications for their enterprise customers rather than on managing the company’s underlying infrastructure. This strategy is paying off for Infor. In the last two years, Infor has released 13 industry CloudSuites, serving more than 45 million users across 96 countries.
Infor and AWS share a common entrepreneurial spirit, driven by a strong desire to continuously disrupt the market and innovate on behalf of our customers. “Our relationship with AWS has always been grounded in a mutual desire to help enterprise customers realize the benefits of cloud software that’s secure, highly available, and accessible,” says Brian Rose, SVP of Infor Labs. “Since going all-in with AWS, Infor accelerated internal development cycles, and can get to market faster, while maintaining high standards for security, compliance and scale.”
Infor continues to disrupt the business application space. As a Technology Partner in the AWS Partner Network (APN) and an important AWS Enterprise customer, Infor has worked closely with teams across AWS, and our two companies have developed a strong relationship. “Infor and AWS are both laser focused on driving value for our respective customers,” says Hal Bennett, GM Global Technology Partners at AWS. “It’s been exciting to watch Infor’s success since going all-in with AWS. We look forward to continuing to support Infor as a customer and partner in the years to come.”
Infor is an APN Advanced Technology Partner, and holds the AWS Healthcare Competency. As we reflect on Infor’s motivations for going all-in, let’s take a look at where Infor is now:
- Infor now offers 13 Infor CloudSuites on AWS, touching a wide range of industries (including Auto, A&D, Corporate, Business, Hospitality, HCM, Rhythm, Fashion, Food and Beverage, Equipment, Distribution, Healthcare, and Public Sector)
- There are over 45 million Infor CloudSuite users globally
- 96 countries access the Infor Cloud
- Infor has over 14,000 employees and customers in more than 200 countries and territories
- It takes Infor less than two minutes (!) to provision customers on automated MT applications
- Infor has had 99% average historical uptime
- The company uses a large number of AWS services to run its platform, including Amazon RDS, Amazon DynamoDB, VPC, and IAM
- Last quarter represented strong revenue growth for Infor, with a sales pipeline driven by its SaaS business (read more here)
Infor is a thought-leader in cloud strategy, and consistently publishes content educating readers on best practices and trends the company observes in the cloud. Check out some of Infor’s latest posts:
- Why cloud should be on the boardroom agenda
- Infor Retail’s revolution: Making it real with Predictix
- Become more effective. Become more connected.
- Manage Growth in 2016: Investing in R&D
Click here to learn more about Infor’s journey on the cloud. Want to read about Infor’s journey as an APN Partner? Don’t miss the Infor Partner Success Story.
Take Advantage of AWS Self-Paced Labs
AWS is celebrating its 10-year anniversary. And to acknowledge and thank our customers and APN partners, we’ve partnered with qwikLABS to offer the entire catalog of AWS self-paced labs and learning quests at no charge through the end of March.
AWS self-paced labs enable you to get hands-on practice working with AWS services in a real environment. We currently offer 90+ labs, ranging from beginner to expert topics. Many labs are also organized into 15 learning quests that help you learn how to work with related AWS services. Labs are a great way to build new skills – and confidence – on AWS.
Here are some ways that you – and your customers – can take advantage of labs this month:
Learn a Service
Experiment with new AWS services or features at your own pace. Our Introduction to AWS series – which is always available to you at no cost – helps you get started working with 30+ AWS services, such as Amazon S3, Amazon VPC, or Amazon DynamoDB. Now you can also take more advanced labs at no cost to practice additional concepts and use cases with these services.
Practice a Use Case
Get comfortable with AWS scenarios for websites, big data, digital media and more. Learning quests have six or more labs each to help you get experience working with related services. When you complete a quest, you’ll earn a badge that you can show off on your resume, website, or LinkedIn profile.
Study for AWS Certification
Preparing to take your AWS Certification exam? Now is a great time to get practice with services and concepts covered on the AWS Certified Solutions Architect exams. Exam Prep Quests have six to nine labs each.
We encourage you and your customers to get practice on AWS this month. To learn more and see the full catalog of labs, visit qwikLABS.com.
Partners in Innovation: Announcing the AWS 2016 City on a Cloud Innovation Challenge
Are you an APN Partner building technology solutions on AWS to help improve citizens’ lives?
Today, we announced the call for entries for the AWS 2016 City on a Cloud Innovation Challenge, a global program to recognize local and regional governments and APN Partners that are innovating for the benefit of citizens using the AWS cloud.
AWS and a panel of worldwide experts will award a total of $250,000 in AWS promotional credits to eight grand prize winners from three award categories: Best Practices, Partners in Innovation, and Dream Big, a category that recognizes the best ideas for a cloud innovation, and award credits for its implementation.
City on a Cloud Innovation Challenge winners will be announced on June 21, 2016, at the AWS Public Sector Summit in Washington, D.C.
Want to learn more about the requirements to enter? Visit the AWS Government, Education, & Nonprofits blog here.
Architecting Microservices Using Weave Net and Amazon EC2 Container Service
In the past, it was far more common to have services that were relatively static. You might remember having a database server that existed on a fixed IP, and you probably had a static DNS mapping to that server. If this information changed, it could be a problem.
However, in the cloud we accept change as a constant, especially when building microservice architectures based on containers. Containers often live only for minutes or hours, and they may change hosts and ports each time they are spun up. When building containerized microservices, a major component of the architecture includes underlying “plumbing” that allows components to communicate across many hosts in a cluster. Generally, the tools allowing this communication also help us deal with the dynamic nature of containers by automatically tracking and replicating information about changes across the cluster. These tools provide functionality commonly known as “service discovery.” Today, we’re going to talk about a popular service discovery option, Weave Net, by APN Technology Partner Weaveworks.
We’re fans of Weave Net for a few reasons, but the most attractive thing about Weave Net is its simplicity. Weave Net allows you to reference containers by name, as you would reference them locally with Docker links, across the entire cluster. That’s it.
Weave Net is also unique among service discovery options because it doesn’t use an external database or a consensus algorithm, but instead uses a gossip protocol to share grouped updates about changes in the cluster. This has interesting implications for partition tolerance, where availability is prioritized over consistency.
Let’s talk CAP theorem!
In a world where the network is unreliable (read: the one that we live in), your distributed system can either be highly available and partition tolerant, or highly available and consistent, but not highly available, highly consistent, and partition tolerant. Service discovery options that use consensus algorithms prioritize consistency, so in network partition events they must sacrifice availability to avoid having inconsistent cluster state.
Weave Net, on the other hand, uses a data structure called a CRDT where nodes in the cluster only make local updates, and replication happens via merged updates to the rest of the cluster. This means that the data structure is eventually consistent, but the lack of a strong consistency requirement allows it to be extremely fast and highly available. (See the fast data path discussion on the Weaveworks website.) It’s important to consider the needs of your system, and if your application prioritizes availability or doesn’t require strong consistency, then Weave Net is an excellent service discovery option.
Microservice design with Weave Net and Amazon ECS
Within Amazon EC2 Container Service (Amazon ECS), you can use task definitions to deploy containers to your ECS cluster. A task definition can include one or many containers, but the key concept to remember is that when you run a task definition, all the containers in that task get placed on a single instance. Ask yourself, “Does my application require a specific combination of containers to run together on the same host?” You might say, “Yes, this is necessary,” if your containers need to share a local Amazon Elastic Block Store (Amazon EBS) volume, for example.
You might also answer in the affirmative if your containers need to be linked. However, Weave Net gives you more flexibility when designing your application. Because Weave Net automatically handles container communication across the cluster, you have a bit more freedom when building task definitions. You’re freed from needing to use local Docker links, so you don’t have to place all the containers that make up your application on the same instance.
As a result, you can define a single container per task definition. Consider our sample application: a Python Flask application on the front end and Redis on the back end. Because these components have different scheduling and scaling requirements, we should manage them independently by building a separate task definition for each container. This one-to-one model is far simpler to think about and to manage than multiple services defined in a single task definition.
Let’s unpack our sample application architecture a little bit. Our front-end application is a simple Python hit counter application. From line 6 we see that we’re building the connection object for our Redis back end. We know that we are going to name the Redis container redis, so we can write our code with this in mind. Weave Net will take care of the rest.
Now we need to build two ECS task definitions. These definitions are really straightforward, since we’re adding only a single container to each task.
Here’s the back-end Redis task (notice that my container name is redis):
{
"ContainerDefinitions": [
{
"Essential": true,
"Name": "redis",
"Image": "redis",
"Cpu": 10,
"Memory": 300
}
],
"Volumes": []
}
Here’s the front-end hit counter task:
{
"ContainerDefinitions": [
{
"PortMappings": [
{
"HostPort": 80,
"ContainerPort": 5000
}
],
"Essential": true,
"Name": "hit-counter",
"Image": "errordeveloper/hit-counter",
"Command": [
"python",
"app.py"
],
"Cpu": 10,
"Memory": 300
}
],
"Volumes": []
}
Next, to scale these components individually, we’ll take these task definitions and wrap a higher-level ECS scheduling construct, known as a service, around them. A service lets us do things like define how many tasks we want running in the cluster, scale the number of active tasks, automatically register the containers to an ELB, and maintain a quota of healthy containers. In our architecture, which has one container per task and one task per service, we can use the service scheduler to determine how many Redis containers and hit counter applications we’d like to run. If we run more than one container per service, Weave Net automatically handles load balancing among the containers in the service via “round robin” DNS responses.
The end result is an ECS cluster that has three container instances and two services—one front-end hit-counter service scaled to three tasks, and a back-end Redis service with one task running.
$ aws ecs describe-clusters --cluster WeaveSKO-EcsCluster-
1USVF4UXK0IET --region eu-west-1
{
"clusters": [
{
"status": "ACTIVE",
"clusterName": "WeaveSKO-EcsCluster-1USVF4UXK0IET",
"registeredContainerInstancesCount": 3,
"pendingTasksCount": 0,
"runningTasksCount": 4,
"activeServicesCount": 2,
"clusterArn": "arn:aws:ecs:eu-west-1:<account-
id>:cluster/WeaveSKO-EcsCluster-1USVF4UXK0IET"
}
$ aws ecs list-services --cluster arn:aws:ecs:eu-west-
1:<account-id>:cluster/WeaveSKO-EcsCluster-1USVF4UXK0IET --region
eu-west-1
{
"serviceArns": [
"arn:aws:ecs:eu-west-1:<account-
id>:service/WeaveSKO-EcsBackendDataService-1KTM3UFB3LKIO",
"arn:aws:ecs:eu-west-1:<account-
id>:service/WeaveSKO-EcsFrontendAppService-1A5RQTSV7LMWE"
]
Weave Net technical deep dive
How does Weave Net provide so much flexibility when you’re designing microservices with no configuration?
Weave Net starts by implementing an overlay network between cluster hosts. Each host has a network bridge, and containers are connected to the bridge with a virtual Ethernet pair, upon which they are assigned important information like an IP and netmask.
Weave Net discovers peers by querying the Auto Scaling API, so you don’t need to configure the overlay network yourself. On each host, Weave Net also runs a component called the Docker API proxy, which sits between the Docker daemon and the Docker client to record events on the host, like a container starting or stopping. The proxy also handles automatic registration of new containers to the overlay bridge.
Weave Net builds an in-memory database of local configuration information that it records from local Docker activity and chooses a random subset of peers with which to exchange topology information (using the gossip protocol). When it’s time to forward communications between hosts, packets are encapsulated in a tunnel header and forwarded to the Linux kernel. The Weave Net router communicates with the Linux kernel’s Open vSwitch module to tell the kernel how to process packets. This approach allows packets to progress straight from the user’s application to the kernel, avoiding a costly context switch from user space to kernel space.
These features result in greatly reduced complexity when designing microservices. Weave Net also provides other niceties like multicast support and round-robin DNS for container lookups. Take a look as we run a dig query against the hit-counter service. You can see that the query returns the three nodes that run the service in random order:
$ docker run 2opremio/weaveecsdemo dig +short hit-counter 10.32.0.3 10.36.0.3 10.40.0.3 $ docker run 2opremio/weaveecsdemo dig +short hit-counter 10.40.0.3 10.32.0.3 10.36.0.3
Weave Scope
The last thing I’d like to point out about Weaveworks is the useful Weave Scope component. Weave Scope is a monitoring and troubleshooting tool that provides a birds-eye view of the cluster, and it can be run either as a hosted/SaaS tool or locally on your cluster instances. It displays all the containers in the system and the relationships among them:
We can also drill down into a specific container to see vital telemetry information:
Lastly, we can open a shell directly into the container. In this screen illustration, we’re taking a look at the output of env inside the container:
Conclusion
When you build microservice-based applications, deciding how individual microservices will communicate with one another requires a lot of thought. Weave Net greatly reduces the complexity involved in standing up microservices and increases flexibility in design patterns. In this blog post, we’ve explored Weave Net features and described how you might use them to design an application in Amazon ECS.
If you’d like to take a look at Weave Net and Weave Scope yourself, you can stand up your own copy of the example architecture from this post by using the following AWS CloudFormation template, which was developed and is maintained by Weaveworks: https://github.com/weaveworks/integrations/blob/master/aws/ecs/cloudformation.json. Keep in mind that this template will spin up resources that could cost you money. To learn more about Weaveworks, visit their website at http://weave.works or take a look at their technical deep dive.
Premier AWS Consulting Partner Blog Roundup – Feb. 10th – Feb. 29th
It’s awesome to see how much cloud thought leadership and educational blog content our Premier APN Partners pushed live in the month of February.
Check out some of the posts a number of our Premier Consulting Partners published from February 10th – February 29th:
- 2nd Watch
- Accenture
- Aquilent
- Bulletproof
- Capgemini
- Classmethod: Classmethod has published a wealth of AWS-specific content in the past couple of weeks. Check out all of their AWS posts: http://dev.classmethod.jp/category/cloud/aws/; here are a few of the posts published…
- ClearScale
- Cloudreach
- Cloudnexa
- Cloud Technology Partners: CTP has published a vast amount of cloud-specific content the past few weeks. Check out all of their posts: http://www.cloudtp.com/insights/cloud-computing-blog/; here are a few call outs…
- Cognizant
- CorpInfo
- CSC
- Datapipe
- Dedalus
- DLT
- Infosys
- Logicworks
- Mobiquity
- NORDCLOUD
- REAN Cloud
- Serverworks
- Slalom
- TriNimbus
- Wipro
Modeling SaaS Tenant Profiles on AWS
Most software companies understand the importance of being customer focused. The adoption of agile software development practices was heavily influenced by the needs of software organizations to connect to, and focus on, the continually evolving needs of their customers.
Now, take this basic reality and imagine how it manifests itself in the world of SaaS (software as a service) applications. With SaaS, your customers may be running in a fully shared environment, and the stakes are even higher. The real challenge for SaaS providers is to leverage the power and value of having a shared environment while accommodating the diversity of their customers’ needs. Striking a balance between these often-competing forces is essential to SaaS solutions.
Building an application that accommodates this level of flexibility and diversity requires diligence. The implications can be very pervasive and can affect multiple dimensions of your SaaS strategy. Ultimately, how you approach this opportunity is likely to directly influence the agility of your offering and its ability to align with the needs of your customers. The approach you choose will certainly have some impact on your ability to respond to market dynamics and competitive challenges.
The need for tenant-driven agility also highlights the intertwined nature of business and technology in SaaS environments. SaaS demands a design, architecture, and deployment vision that enables and supports the ability of your business to offer customers options that align with their specific needs.
In this blog, we’ll look at some of the considerations that go into capturing data on your tenants with an emphasis on identifying some of the key areas that could shape your system’s architecture. The landscape of possibilities here is broad, and my hope is to provide a glimpse of some of the factors that you may include in a broader assessment of your tenant profile.
Assessing Tenant Needs
Developing a tenant profile is all about understanding the value systems and domain forces that will influence a customer’s willingness to adopt your SaaS solution. Your ability to understand and categorize customer needs can help determine how and where you might need to support tenant variations in your underlying design and architecture.
Here are some of the typical questions that SaaS teams examine as part of this assessment:
- What are some of the security considerations that might influence your customer’s willingness to run in a multi-tenant environment?
- Are there specific standards or compliance criteria that must be met by some or all of your tenants?
- Are there tenants who may have specific data governance requirements?
- Are there other SaaS solutions that might be used in combination with this application?
- Are there tenants who will demand some level of isolation from other tenants?
- Are there tenants who will be willing to run in a fully shared environment?
- Are there optimizations, workflows, or product features that could be offered as value-added options?
- Are there any significant variations in how each tenant may need to respond to spikes in user load/activity?
- Do one or more tenants require customization of the application’s flow, business rules, appearance, and so on?
- Are there specific SLA requirements/expectations that may be imposed by some tenants?
This list is only meant to serve as a starting point. The nature of these questions is to tease out important traits that may distinguish the needs of specific tenants. Working through this list (and adding your questions) should give you a good sense of the range of options you may need to support in your solution.
Developing Tenant Personas
Once you have a well-understood list of tenant criteria, your next goal would be to determine how these criteria might be clustered together to represent different personas or families of tenants in your target audience.
This approach mirrors the agile concept of defining personas. The idea is to clearly capture and articulate the characteristics and requirements associated with each tenant type. As a part of this exercise, teams may assign tenant persona names that can be used as a common reference point for the broader team. The image below provides a simple example of how you might go about defining a persona.
Identifying personas should not be a heavyweight process. Invest enough energy to test yourself and the boundaries of your tenants’ requirements, but don’t iterate on this too long. You simply want to gather enough knowledge to ensure that you have identified the likely points of inflection in your SaaS architecture.
Aligning Architecture and Personas
The overarching goal of defining personas is to determine what values will shape the design of your SaaS application. Once you’ve identified your target personas, you’ll have the data points you need to determine the dimensions of flexibility and customizability you need to address with your underlying design.
While the personas for each SaaS application will vary, there are some common themes to consider as you begin to align your personas with your architecture. These themes often include isolation strategies, tenant policy management, metering models, and data access patterns. The sections that follow will explore how each of these areas can influence the design of your solution.
Tenant Isolation
Often, you can address the compliance and security requirements of your tenants by applying one or more isolation strategies. Tenants may require complete and total isolation from other tenants, or they may just need isolation at one particular layer or dimension of their environment.
The introduction of isolated tenants creates natural opportunities to define tiers of your product offering. Tenants who demand more isolation will easily understand how the value of that isolation justifies the costs associated with a higher-priced tier. Isolation also equips SaaS organizations with a mechanism for offsetting the increased costs associated with providing isolated infrastructure.
While you may have tenants who demand isolation, this does not mean every tenant will require an isolated solution. The challenge is to strike a balance between addressing the edge cases while continuing to offer shared, multi-tenant solutions where possible. The result is often a hybrid model where some tenants reside in a fully shared space while others are provisioned with some level of isolation.
The following diagram provides two examples of hybrid isolation models you can implement on Amazon Web Services (AWS). The image on the left depicts an approach that offers some tenants full isolation and others a shared environment. Tenants 1 and 2 presumably had requirements that warranted isolation and opted into this model, while the remaining tenants were willing to run in a shared environment.
The diagram on the right shows how you might implement a hybrid model, where isolation is achieved at different tiers of the architecture. The web tier is delivered as a shared environment while the application tiers are isolated for each tenant.
These are just two examples of isolation patterns. AWS provides constructs that can be leveraged to address a fairly diverse set of tenant isolation needs. The AWS stack includes account, networking, security, and storage constructs that enable a wide range of strategies for partitioning a tenant’s footprint. We won’t dig into each individual strategy in this post, but more information is available in the Tenant Isolation Architectures whitepaper.
Centralized Tenant Policies
One common way to address the varying needs of your tenant personas is to introduce a centralized model for managing tenant policies. Tenant policies enable you to customize many dimensions of the tenant experience. Performance, workflows, appearance, feature access, service-level agreements (SLAs)—all of these options can be potentially configured through tenant policies.
The design of your application directly influences the level of flexibility you’ll have in building and applying these policies. First, you’ll need to introduce a service that manages tenant configuration information. The diagram above provides a conceptual view of how these policies would be managed, acquired, and applied. Each tenant’s experience could be altered or shaped at any of the tiers of your application design based on the configuration of tenant policies.
Where this concept gets its power is in a number of levers and knobs you’ll have available to configure tenant workflows, performance, and so on. An application that has been decomposed into finer-grained services is going to allow for more granular control over the tenant experience, allowing you to support a wider range of tenant personas. The presence of these policies tends to put you in a better position to respond to new tenant needs that might surface as your product evolves.
The introduction of these tenant policies may also influence how you apply AWS constructs in your environment. You can imagine, for example, that a tenant policy might correlate to an Identity and Access Management (IAM) policy to control the visibility and control that is given to a tenant or one of the tenant’s users. Tenant policies also might shape the custom metrics that you capture with CloudWatch.
Metering Tenant Activity
In many cases, tenant personas are driven directly by consumption. To support these personas, you’ll need to design and instrument your application with mechanisms that will allow you to capture and aggregate a rich set of consumption metrics. These metrics should span all the moving parts of your system, allowing you to construct a comprehensive view of the infrastructure footprint being imposed by each tenant.
To create a complete metering picture of tenant activity, you’ll need to acquire data from multiple sources. The Amazon CloudWatch service is a good source for surfacing your tenant metrics. Amazon CloudWatch natively supplies access to consumption that spans most of the core metrics you’ll want to include in your tenant profile. It also supports the publication of custom metrics that correlate to your application’s features and functions. You might, for example, be able to determine that the use of a particular application feature directly correlates to a spike in disk or memory utilization.
In cases where you have isolated tenant infrastructure, you’ll want to think about how you might use tagging or separate accounts to identify resources that are associated with a specific tenant.
The last bit of metering you’ll need to consider is how (or if) you plan to apply policies based on tenant consumption. You’ll need to determine how your system will respond as tenants near or exceed consumption thresholds. You may choose to wire these policies up to Amazon Simple Notification Service (Amazon SNS) and to Amazon Simple Email Service (Amazon SES), for example. In some rare cases, SaaS providers might even disable portions of their application’s functionality when a tenant exceeds a threshold. The Amazon API Gateway’s throttling capabilities could be a good fit for this scenario. One common approach is to allow tenants to burst over their consumption threshold on a periodic basis and only enforce constraints when they being to exceed their limits on a more regular basis.
Data Access Optimization
Storage is not an area that gets a lot of attention when we think about personas and how we might distinguish tenants. Instead, we tend to view storage as an all-or-nothing proposition where all tenants get the same behavior. However, given the wide array storage options that are available on AWS, it makes good sense to consider how you might leverage these different storage models to support the different tiers of your SaaS system.
This concept connects directly to the tenant policies section described in the previous section. Through these policies, you can offer tenants different models for accessing and storing data. Combine this with the rich set of storage options available on AWS, and you have a fairly diverse set of options at your fingertips. You might support completely different storage options for tenants (RDS, DynamoDB, S3, Glacier, and so on). You might support separate policies for how data is archived and moved from one storage model to the next. Or, you might have separate throughput policies for each tenant. The range of options is very broad.
Cost is often a key motivator for optimizing data access. If your solution has a heavy storage footprint that is a significant portion of your tenant costs, then developing storage optimization strategies for different personas is an opportunity to align your costs with your tenant tiers.
Support Automation
Support represents another area where there is often variation among SaaS tenants. It’s natural for organizations to offer different levels of SLAs to different types of tenants.
In order to maximize your ability to support more demanding SLAs, you should think about how and where you may want to introduce automation that will trigger support activity. Your focus should be on proactively detecting issues and triggering the creation of support tickets. Each organization is going to have its own processes and models for driving support. The key is to determine what level of automation is needed, and what mechanisms may be used to detect and trigger the support model SLAs you’ve defined for each of your tenant personas.
AWS provides mechanisms that can assist with automating your support policies. You can use CloudWatch events, for example, to trigger a support workflow. Lambda functions could also be applied here to introduce any custom functions that would be used to automate your support process.
Applying YAGNI
The software development and agile communities have often advocated the YAGNI (you aren’t gonna need it) principle. This principle promotes the idea of designing only for the set of features and capabilities that you know are required today. The goal is to avoid investing in flexibility and generality that hasn’t yet earned its way into your solution.
You should consider this rule of thumb when you look at your personas and the needs you’re addressing with your solution. Yes, where possible, you’d like to accommodate generality that will promote and enable a range of tenant personas. At the same time, you don’t want to introduce abstractions or complexity that is not of immediate need or value to your current customers. You must find a way to strike a balance between architectural and design models that are enabling your business, and those that are simply laying a foundation for flexibility that may never be required.
As you think about decomposing your application into services and abstracting out tenant policies, you’ll likely find yourself right in the heart of the YAGNI challenge. Certainly, the more you lean toward more granular services and a more configuration-driven model, the more prepared you will be to support tenant variations. It’s all about finding the boundaries of what’s immediately useful, what’s just a good principle, and what might be overkill for your current needs.
Making Agility a Priority
As a SaaS solution provider, you should always consider agility and how your personas may or may not be influencing your ability to respond rapidly to customer feedback and changes in market dynamics. So, while you certainly want to embrace the varying requirements of your tenant personas, you also want to be sure that the level of customization and variation you’re accommodating doesn’t undermine the fundamental agility goals of your business.
This is especially relevant as you look at tenant isolation schemes. Typically, supporting isolation also means supporting more complex and potentially more fragile provisioning and deployment models. It also tends to limit your ability to roll out new features and capabilities rapidly. It can even affect the efficiency of your management and monitoring environments.
Leveraging AWS Services
AWS brings a rich collection of services to the SaaS domain, and provides a variety of different strategies to address the current and emerging needs of your SaaS customers. You can apply networking and account constructs to achieve multiple flavors of tenant isolation. You can use the continually evolving list of AWS storage options to offer tenants a range of different experiences. With Amazon Elastic Compute Cloud (Amazon EC2), Amazon EC2 Container Service (Amazon ECS), and AWS Lambda, you also have a diverse set of compute models that can influence the profile and footprint of your SaaS solution.
Summary
In this post, I’ve outlined the value of understanding the profiles of your tenants and aligning your design with the key points of variation for each tenant persona. Ultimately, your goal is to build a solution that offers clear, distinguished boundaries of value to each persona. You can then use these boundaries as a natural tool for creating product tiers that match the business needs of your customers with the broader cost considerations of your SaaS offering.
Whether you’re starting from scratch or evolving an existing SaaS solution, you should always have some sense of the current and evolving needs of your tenants. Even if you’re not formally tiering your product into separate offerings, you can still use your awareness of the range of tenant requirements to shape your architectural direction. Insights into your tenant profiles can lead you to new and interesting ways to leverage AWS services and capabilities in patterns that you may not have originally anticipated.
New on the AWS Enterprise Blog: The Future of Managed Services in the Cloud
As part of his Enterprise Cloud Journey series, Stephen Orban, Head of Enterprise Strategy at AWS, published a piece today on the AWS Enterprise Blog about how managed services have evolved in the cloud. We’ve spoken at length on the APN Blog about the importance of understanding how managed services are different in the cloud, and what we define as next-generation MSPs. These MSPs are firms who, as Stephen puts it, “are able to streamline their operations, focus more on value-added services, and optimize their own cost structure.” Next-gen MSPs help enterprises manage their steady state operations while also helping them leverage DevOps and develop a culture of experimentation, which Stephen discusses at length in the post.
Click here to read the full post, and keep an eye out for future posts in the series.
