Headless CMS Blog

The beauty of AWS Lambda is that it allows you to deploy and execute code without needing any physical server. In other words, you can set up “serverless” architecture using AWS Lambda.

When deploying your code, you may want to deploy it in various environments (such as testing, development, and production), so that you can test your code before going live.

This article takes you through the steps of setting up Lambda functions in different environments by using the AWS Lambda function alias and versioning. By the end of this blog, we will have learned how to do the following:

• Create an alias for AWS Lambda function
• Associate the AWS Lambda function alias with the AWS API Gateway stage
• Secure the AWS API Gateway stage with API Key and Rate Limiting
• Reassociate versions with the alias

These are the essentials for managing different environments within the serverless system and for the smooth rolling out of releases.

Create an Alias for AWS Lambda Function

The following section shows you how to create environment aliases for a Lambda function and associate them with function versions. We will create two aliases for the development and production environments as an example.

Create a Lambda function

To create a Lambda function, follow the steps below:

1. Login to your AWS Management Console, select AWS Lambda service from the Service list.
2. Click on the Create function button, and then the Author from scratch option.
3. Configure the lambda based on your requirements. Choose Node.js 12.x as your run-time language and click on the Create function button.

Publish Version

After creating a Lambda function, you can publish the version as follows:

1. Go to the newly created version.
2. Select Publish new version from the “Actions” drop-down menu:

3. Publish the new version with an appropriate version description, for example, “Initial Stable Version.”

Create an Alias for Each Environment

The next step is to create an alias for each environment, as shown below:

1. From the Actions drop-down menu, select Create a new alias.
2. Add the alias Name, Description, and Version, as shown in the following example:

Note: You have to perform this step twice, first for the development environment and second for the production environment.

3. The version for the development environment should be $LATEST and for the production environment, it should be 1 which we created in the Publish Version section above.

These steps ensure that a specific version of the Lambda function is assigned to the production environment, and the latest version is assigned to the development environment.

Associate the AWS Lambda Function Alias With the AWS API Gateway Stage

This section shows how to create a new AWS Lambda API Gateway and associate the production and environment stages with the respective Lambda function aliases.

Create a New REST API

REST APIs help the Lambda function to fetch and send data. So, the next step is to create a REST API using the steps given below:

1. Log in to AWS Management Console and select API Gateways from the services list.
2. Click on the Create API button.
3. On the Choose an API type page, go to the REST API option (the public one) and click on Build.
4. On the next page, ensure that the Choose the protocol section has REST checked, and the Create new API section has New API checked. Enter the API name in the Settings section and click on Create API.

5. Now add a new resource to the API gateway as shown in the following screenshot:

6. Add a simple method of the required type. In this example, we have created a GET method for "/demo-resource".

Deploy and Add Stage Variable

Now that the API is created, let’s deploy it.

1. Deploy the API in two new stages and name them development and production.
2. In the Stages tab of API Gateway, navigate to each deployed stage and add the stage variable with key as lambdaAlias and the name of the stage as value.

Associate Stage With Lambda Alias

1. In the Resources tab of API Gateway, select the REST API method that we created in the above.

2. Click on Integration Request, which is associated with Mock by default.
3. Select the Lambda region in the Integration Request section and set name to the name of the Lambda function followed by :${stageVariables.lambdaAlias}. In our example, we have named it demo-function:${stageVariables.lambdaAlias} as shown below:

5. After clicking Save, a prompt appears with a CLI command and instructions to add permission for each stage. Execute the command from AWS CLI by replacing :${stageVariables.lambdaAlias} with each stage name.
6. After you execute the command, your Lambda stages successfully attach to the respective Lambda function aliases.

Securing AWS API Gateway Stage With API Key and Rate Limiting

The following section shows how to add the API key security to the API gateway and apply appropriate rate-limiting to safeguard our respective environments.

Create Usage Plan

1. Create an API usage plan for development and production environments with appropriate throttling and quota for the respective stage.

2. Note: For more information on the rate-limiting algorithm, read the following guide: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html.
3. Now associate the API gateway stage with the respective usage plan while creating. In our use case, we associate the development usage plan with the development stage of the API gateway.

Create and Add Api Key to Usage Plan

1. Select each usage plan and go to the API Keys tab.

2. Click on Create an API Key and add it to the Usage Plan and add the API key.

3. After creating the API key, click on the newly created API key from respective usage plans.

Make API Key Mandatory For Resource

1. Go to the Resource Method created for the API.
2. Within the Method Execution section, click on Method Request.
3. From the Settings section, set API Key Required drop-down to true.

4. Deploy the API gateway to both the created stages for respective environments.

After completing the above steps, you will require the respective API keys to access the stages of the API gateway associated with different aliases.

Reassociating Version With Alias

This section demonstrates how you can update the alias version for a Lambda function, which you can use to either associate a new version to a production alias or revert code to an earlier version.

Publish New Version

1. Publish a new version of the latest Lambda function when development is completed.
2. This step is optional if you are trying to revert the code to an earlier version.

Switch Alias

Select production alias from the Qualifiers drop-down of the AWS Lambda function.

Update Alias Version

1. After switching alias from the drop-down, scroll down to the Aliases section of the Lambda function and select a new version for the alias.

2. Click on Save to complete the reassociation of the version with the alias.

The above steps should help you set up multiple environments in AWS Lambda. We can ensure that the development URL always gets the result from the latest Lambda function and the production environment is bound to one fixed version of the Lambda function.

As digital business expands, so does the enterprise software market.

The good news is that modern software options can support any digital experience you dream up. The bad news is that finding these tools can be like finding a needle in a marketing buzzword haystack.

One term that is quickly becoming part of software design and marketing lingo is MACH (microservices, API-first, cloud-native, headless). MACH technologies are built from the ground up to be modular, pluggable, scalable, and to support a continuously evolving digital experience.

Enterprises are eager to adopt these new principles. 80% of 2020 IT budgets have cloud applications as a top priority while legacy system integration was only a priority in 24%.

Legacy vendors have noticed this trend, and many have tried to make “quick-fixes” when it comes to cloud and APIs, spinning their marketing message to match.

When everyone is using the same language, it can be hard to determine which technology is the real deal. Here are six ways to look behind the marketing curtain and select the best modern tools for your experience.

1. No “All-in-One” Messaging

Back when “digital business” meant merely having a website, it made sense for one platform to be able to support all of a company’s digital needs. As the scope of digital businesses expanded — from marketing to commerce to customer service and everything in between — so did the amount of functionality needed to manage it.

Some larger platforms that would like to keep their business model of being the one-stop-shop for digital, have tried to add on more functionality to keep up. They build their product with the intention that customers will exclusively use the functionality in the platform, and don’t make it very easy to substitute with other tools. This means that if you choose a platform for its best features, you also get locked into the not-so-great ones.

Digital Experience is too varied for any single vendor to master every part of it. As digital becomes a major way that businesses differentiate themselves, the chances of finding a single platform that aligns perfectly with every goal of an enterprise’s roadmap are slim.

MACH tools address this issue. Built to integrate at a functionality level, they aim to be a part of a “composable enterprise” where a business has the freedom to assemble a toolkit that fits their unique needs. They support modern approaches to complex projects, such as hyper-personalization, that require data orchestration across multiple tools and teams. MACH vendors focus on proving the best solution for their digital experience domain and integrating easily with everyone else.

What to look for:

• No “all-in-one” messaging that claims the platform can manage the entire digital experience.
• Documentation and guides on integrating with other tools, especially in the classes of technology most crucial to your ecosystem.
• The five factors listed below exist in technologies built to integrate from the ground up.

2. API-First, Not API-Added

Across functionalities, over 80% of enterprise employees say that data integration is “critical” or “very important” to business. Even if the “all-in-one” platforms want to be the single source of experience functionality, they know they aren’t the only source of data to power that experience. Every enterprise software on the market will provide some sort of API to share data.

However, there is a big difference between platforms that have added APIs to a monolithic codebase and ones that have been built with APIs from the ground up.

APIs are often compared to Lego bricks, in that their standardized nature lets you click different applications to each other. Some platforms were originally built as full, monolithic boxes before APIs became a standard design practice. They have added APIs by gluing Lego bricks to the outside of this box, and wiring up the inside of the box to push and pull specific data through this brick. For some tools, like ERP and CRM, this push and pull of data is all that is needed.

For customer experience tools, like content management and ecommerce, there needs to be more flexibility than a few specific Lego bricks can provide. MACH tools are built with APIs from the ground up, so that every functionality — across the management console, product UI, back-end, etc. — is accessible through an API. The entire solution is built with Lego bricks, and a business can organize these modular functionalities to fit unique plans, projects, and other digital experience tools.

What to look for:

• There is documentation available for multiple APIs.
• There are no software add-ons or plugins; functionality is extended exclusively through APIs.
• A product history that has always been API-first. No announcements of “introducing APIs.”
• If specifically a headless technology, there should be no presentation layer available. A presentation layer that has been decoupled is a sign that the product has added APIs.

3. Everything as a Service

The API-first design, combined with being cloud-native, allows MACH software to provide functionalities as a collection of microservices so each microservice can be individually tested, updated, deployed, and scaled.

This is why most MACH software is available as Software-as-a-Service (SaaS). In this subscription licensing model, the vendor centrally hosts the application and provides access via the cloud. Resources, and the cost of those resources, can be easily scaled up and down as needed.

Just as having an API doesn’t make you API-first, having a cloud offering doesn’t make you SaaS. As more businesses head towards cloud architecture, legacy software vendors are offering their software in the cloud as managed services. The vendor will take care of the hosting, but the software still requires custom installation and manual upgrades.

SaaS, on the other hand, requires no installation. Because individual microservices can be upgraded and delivered instantly, updates are continuously delivered. There is no version 1, version 2, version 3, etc. of the software that requires re-installation — the software is a continuously evolving application that is automatically up to date.

Some legacy vendors will say that managed services let you customize your platform, while SaaS is an off-the-shelf option. And, to be fair, the off-the-shelf standardization of the services is what allows SaaS products to upgrade automatically. However, customization shouldn’t be happening at a platform level anyways.

Let’s take it back to the Lego example. For a managed service offering, the vendor will customize that monolithic box to push and pull the data you want through the glued-on Lego brick. A company pays a flat price for the whole box, regardless of how much of it they use. When the vendor updates their box, they will help rewire this new version of the box to make sure it works like the old one. It is customized, yes, but it requires custom work for each new version.

The SaaS offering, on the other hand, is made up of Lego bricks that are standard for everyone. That standardization means that when a brick is updated, that update can be given to everyone, and that brick will be compatible in any previous scenario — no custom work required. Updates can be scaled, so customers get more of them. Companies are then free to assemble those bricks to meet custom goals and only pay for the bricks they use.

What to look for:

• No software download required.
• A subscription model of payment based on resources or users. No licensing model based on versioning.
• Upgrades are rolling and automatic, there is no service cost or time estimated for version upgrades.

4. Supports Modular Implementation

Due to all the above factors, MACH technologies offer businesses significant benefits. They let companies escape the re-platform cycle thanks to modular implementation.

Legacy tools usually require a “big bang” launch. Going live with a new software means completing ripping out and untangling the dependencies of your old solution, re-mapping those to the new one, and ensuring the entire setup is perfectly in place before launching — or risk a cascade of errors.

With MACH tools, the process is less “ripping” and more “clicking.” This is due to a few different reasons.

First, because they aren’t meant to be “all-in-one” platforms, MACH tools make it easy to integrate with the investments you already have — including the platform they are set to replace. Teams can have access to new functionalities right away, while gradually weaning off of the legacy platform.

Second, their decoupled services can be tested, updated, and deployed independently. Multiple teams can work in parallel, and changes can be made without the risk of cascading errors.

Third, because of their independent nature, projects can go live one at a time. You can get a fully functioning project up and running in a few weeks, such as a new checkout or customer support process, and evolve your experience step by step.

MACH tools are designed to evolve. To learn more, and for real examples of companies making the switch to MACH, check out the recently published ebook: Break the Replatform Cycle with MACH Enterprise Architecture.

What to look for:

• It should be possible to use any functionality of the product on its own, without requiring the full kit and kaboodle to get started.
• Headless software. While not all MACH solutions are headless, it is a good indicator that the software has independent services.
• Reference customers who have had success with modular implementation.

5. Offers A Proof of Concept

Always try before you buy. If a vendor claims their software provides agility and speed, but they are hesitant to demonstrate that with a proof of concept — that’s a red flag.

Hacking your way past a vendor’s sales deck is the best way to see behind the marketing curtain. Choosing a real business case for this project lets you ensure that the solution fits into your ecosystem, and proves that the software holds up beyond the polished demo.

It also gives you a chance to see if the vendor is the right match to partner with. MACH tools are a new venture for many companies, and it’s essential to have a vendor that you feel you can rely on to help you figure it out.

What to look for:

• The APIs, documentation, and SDKs are easy to work with.
• The UI is easy for all relevant teams to adopt.
• The vendor’s customer service is helpful throughout the process.

Emphasis on Partnership

Digital is the new competitive battleground, which means companies need unique experiences that set them apart. This means that businesses need to choose a network of software providers that are willing to work with them on initiatives that haven’t been done before.

Along with the support for new experiences, the SaaS model requires businesses to trust vendors to be transparent about day-to-day performance. With SaaS, enterprises are relying on vendors to be up to date with security, stability, and performance — and upfront about any issues that arise.

On top of that, because there is no “all-in-one” platform market anymore, these vendors not only need to work well with you but with each other. Larger digital projects will require effort from multiple providers, and poor communication between parties can slow down efforts. When running the proof of concept, a kick-off meeting that includes your current key vendors can help determine if everyone is a good fit. 

What to look for:

• Customer reviews on sites like G2, Capterra, Gartner, and Forrester.
• Recommendations from current vendors that you trust.
• Ask what recent feature has been added based on a customer suggestion, if they partner with customers on new initiatives they should have an answer.

For a deeper look at the benefits of MACH tools and how real companies are making the switch to a MACH architecture, check out our ebook: Break the Replatform Cycle with MACH Enterprise Architecture.

Ready to evaluate a vendor? Try these 30 RFP questions to ask your headless CMS candidates.

REST is an API design architecture that has become a norm for implementing web services in the last few years. It uses HTTP to get data and perform various operations (POST, GET, PUT, and DELETE) in JSON format, allowing better and faster parsing of data.

However, like all technologies, REST API comes with some limitations. Here are some of the most common ones:

• It fetches all data, whether required or not (aka “over-fetching”).
• It makes multiple network requests to get multiple resources.
• Sometimes resources are dependent, which causes waterfall network requests.

To overcome these, Facebook developed GraphQL, an open-source data query and manipulation language for APIs. Since then, GraphQL has gradually made its way into the mainstream and has become a new standard for API development.

GraphQL is a syntax for requesting data. It’s a query language for APIs. The beauty, however, lies in its simplicity. It lets you specify precisely what is needed, and then it fetches just that — nothing more, nothing less.

And it provides numerous other benefits.

The following covers some of the most compelling reasons to use GraphQL and looks at some common scenarios where GraphQL is useful.

Why Use GraphQL?

Strongly-Typed Schema

All the data types (such as Boolean, String, Int, Float, ID, Scalar) supported by the API are specified in the schema in the GraphQL Schema Definition Language (SDL), which helps determine the data that is available and the form in which it exists. This strongly-typed schema makes GraphQL less error-prone and provides additional validation. GraphQL also provides auto-completion for supported IDEs and code editors.

Fetch Only Requested Data (No Over- or Under-Fetching)

With GraphQL, developers can fetch exactly what is required. Nothing less, nothing more. The ability to deliver only requested data solves the issues that arise due to over-fetching and under-fetching.

Over-fetching happens when the response fetches more than is required. Consider the example of a blog home page. It displays the list of all blog posts (just the title and URLs). However, to present this list, you need to fetch all the blog posts (along with body data, images, etc.) through the API, and then show just what is required, usually through UI code. This over-fetching impacts your app’s performance and consumes more data, which is expensive for the user.

With GraphQL, you define the fields that you want to fetch (i.e., Title and URL, in this case), and it fetches the data of only these fields.

Under-fetching, on the other hand, is not fetching adequate data in a single API request. In this case, you need to make additional API requests to get related or referenced data. For instance, while displaying an individual blog post, you also need to fetch the referenced author’s profile entry so that you can display the author’s name and bio.

GraphQL handles this well. It lets you fetch all relevant data in a single query.

Saves Time and Bandwidth

GraphQL allows multiple resource requests in a single query call, which saves time and bandwidth by reducing the number of network round trips to the server. It also helps to prevent waterfall network requests, where you need to resolve dependent resources on previous requests. For example, consider a blog’s homepage where you need to display multiple widgets, such as recent posts, the most popular posts, categories, and featured posts. With REST architecture, displaying these would take at least five requests, while a similar scenario using GraphQL requires just a single GraphQL request.

Schema Stitching for Combining Schemas

Schema stitching allows combining multiple, different schemas into a single schema. In a microservices architecture, where each microservice handles the business logic and data for a specific domain, this is very useful. Each microservice can define its GraphQL schema, after which you use schema stitching to weave them into one schema accessible by the client.

Versioning is Not Required

In REST architecture, developers create new versions (e.g., api.domain.com/v1/, api.domain.com/v2/) due to changes in resources or the request/response structure of the resources over time. Hence, maintaining versions is a common practice. With GraphQL, there is no need to maintain versions. The resource URL or address remains the same. You can add new fields and deprecate older fields. This approach is intuitive as the client receives a deprecation warning when querying a deprecated field.

Transform Fields and Resolve with Required Shape

A user can define an alias for fields, and each of the fields can be resolved into different values. Consider an image transformation API, where a user wants to transform multiple types of images using GraphQL. The query looks like this:

Apart from the advantages listed above, there are a few other reasons why GraphQL works well for developers.

• GraphQl Editor or GraphQL Playground where entire API designs for GraphQL will be represented from the provided schema
• The GraphQL ecosystem is growing fast. For example, Gatsby, the popular static site generator, uses GraphQL along with React.
• It’s easy to learn and implement GraphQL.
• GraphQL is not limited to the server-side; it can be used for the frontend as well.

When to use GraphQL?

GraphQL works best for the following scenarios:

• Apps for devices such as mobile phones, smartwatches, and IoT devices, where bandwidth usage matters.
• Applications where nested data needs to be fetched in a single call. For example, a blog or social networking platform where posts need to be fetched along with nested comments and details about the person commenting.
• A composite pattern, where an application retrieves data from multiple, different storage APIs. For example, a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, and third-party analytics tools to capture end-user interactions.

• Proxy patterns on the client side; GraphQL can be added as an abstraction on an existing API so that each end-user can specify response structure based on their needs. For example, clients can create a GraphQL specification according to their needs on a common API provided by FireBase as a backend service.

In this article, we examined how GraphQL is transforming the way apps are managed and why it’s the technology of the future. Here are some helpful resources to help you get started with GraphQL:

• https://graphql.org/
• https://github.com/graphql/graphql-spec

Legacy technology, systems, and tools that require outdated methods are nearly impossible to avoid. Digital business is evolving so quickly that a technology purchased just a few years ago might already be considered “legacy.” It’s no surprise that 64% of IT leaders say a top factor in their budget is a need to upgrade outdated infrastructure.

Legacy tools are not just frustrating to work with, they slow business down. In a 2019 survey, two-thirds of developers said that maintenance of a legacy system and technical debt hinder improved productivity. The catch-22 is that removing these legacy systems, and detangling the spider web of dependencies and customizations that have been built around them, can feel like even more effort than maintaining them.

Of course, the custom workarounds needed to keep legacy tools running also add up, making the barrier to change larger. As Tom Morgan, Director of Digital at The Spectator, put it, “In terms of ability to innovate, everything had a cost associated with it, which put us off doing anything risky. That meant our technology was stagnating — as was our ability to serve customers.”

Morgan and his team at The Spectator tackled this problem head-on by completely modernizing their architecture (full story in the newly published enterprise architecture ebook). Still, many enterprise companies need a way to embrace new tools without a significant infrastructure project.

Businesses need a way to modernize their digital experience, safely step off legacy technologies over time, and create a framework that doesn’t require a “rip-and-replace” process to evolve in the future.

The Emperor Has No APIs (but MACH Tools Do)

Luckily, businesses looking for new solutions have a good pool to choose from because enterprise software is having a hot moment right now. The rise of customer expectations, the expectations of employees familiar with modern consumer technologies, and the rapid advancements in programming and cloud computing have led to advanced software designed for the speed, scale, and flexibility needed by today’s digital business.

The need for software to help businesses grow quickly, exponentially, and in multiple ways — also known as being “future-proof” — has found its way into the messaging of many vendors. They know that if they aren’t omnichannel and integration friendly, their tool is obsolete. For some vendors, the solution was to “modernize” their existing software by wrapping it in APIs.

But merely having an API doesn’t make a solution ready for modern business. If the software still requires manual updates, only integrates with a limited selection of other tools, or has a monolithic structure behind those APIs — there’s a good chance it’s a legacy tool in disguise.

Enter MACH tools, a growing trend of software designed with the principles of microservices, API-first, cloud-native, and headless. These tools are API-first, not API-added. From the ground up, MACH technologies are built to be modular, pluggable, scalable, and support continuous development.

Thanks to their modularity, MACH tools are a solution for enterprises that need to quickly alleviate the pains of an outdated experience while gradually stepping off legacy tools.

Stop Vendor Lock-In

It makes business sense for software vendors to have their customers (you) use their product for the majority of the digital experience. The more you rely on their software, the less likely you are to replace it. Back when “digital business” meant merely having a website, this also made sense for the enterprise - one vendor and one contract to cover all your digital needs.

But as digital needs expanded and became unique to individual businesses, the “all-in-one” platform became more of a burden than a benefit.

For example, say there is a platform that is top of the line in commerce, but the content and search capabilities are subpar. If their goal is to be your “core” platform, chances are they aren’t going to make it easy to integrate with other content and search tools. Choosing the platform for its best feature means being locked into its not so great ones.

Designed with the understanding that an enterprise’s digital needs are too complex for a singular “all-in-one” platform, MACH tools support a composable enterprise, where businesses have the freedom to select, integrate, and replace any tool down to the level of individual functionality.

For instance, while Contentstack’s full-text query search can work for smaller sites, it wouldn’t be the best option for sites with thousands of content items that need dynamic search. So Contentstack recommends integrating with leading search platforms and provides guides on how to do so. We focus on delivering the best-in-class headless CMS and integrating easily with everything else.

This focus on integration helps alleviate a second way that businesses get locked in by software, when it’s not just features they are stuck with but the broader solution ecosystem.

With their more monolithic architecture, legacy tools require custom code, plug-ins, or workarounds to support new initiatives. Over time this becomes a hairball architecture, with dependencies, created one at a time, sometimes by people who don’t work at the company anymore. Trying something new feels like it might trigger a domino effect of errors across these dependencies, and untangling the ball would take too much time. Your experience is locked into what is already there because innovation feels like too much time and risk.

MACH technologies are relatively standardized. Every functionality is accessible through an API — so there are no plug-ins or workarounds needed. Additionally, their microservice design keeps functionalities tightly coupled to one another, so if there is an issue in one functionality, there is no risk of a cascade of errors. Another powerful functionality is using an event model that includes webhooks that enable intercepting events and taking custom actions. Adding new functionality, or trying new initiatives, can be done quickly with minimal risk.

Overall, this makes MACH solutions less “sticky.” Meaning you keep them in your ecosystem as long as they are still the best fit, not because they are too hard to remove.

End the Replatforming Cycle

The modularity of MACH tools means that reorganizing your solution ecosystem is less “ripping” and more “clicking.” Simply put, these tools benefit from being designed after APIs and microservices became a widespread design practice instead of having to retrofit a monolithic codebase into a modular world. MACH technologies are API-first, not API-added.

Because they are created from a foundation of microservices and exist natively in the cloud, these tools can be offered as Software-as-a-Service (SaaS). This means that you subscribe to only the resource you use and you can autoscale these resources up and down. Upgrades to the services happen automatically and continuously — no manual versioning is required. While upgrading to a new version may not be the same as replatforming, if the latest version of a software loses backward compatibility, it can require nearly as much effort.

A services model also means that you can modularly implement MACH tools. Because MACH tools are composed of individual services, you can start on any corner of the experience with any MACH tool (even with specific functionalities) and be sure that as you expand the experience those services will be compatible with future additions and changes. As-a-service products let you break away from the “stop-rebuild-restart” pattern of monolithic tools.

Step Off Gradually

While the ease of upgrading architecture once MACH tools are in place is excellent, the first replatforming pain to tackle is how to remove the current legacy system without disrupting business.

Because MACH solutions can be added service by service, businesses can start decoupling their architecture without entirely ripping out their legacy tools. Key functionalities can be up and running quickly, so teams can go ahead and start making improvements to the experience, and businesses can gradually untangle legacy dependencies one functionality at a time.

In our latest ebook, we interviewed enterprise technology directors and solution consultants who moved from monolith to MACH. They shared advice on first steps, evaluating vendors, and what they learned about transitioning to a modern architecture. If you’re curious to learn more, we recommend reading: Break the Replatform Cycle with MACH Enterprise Architecture.

Contentstack was recognized by the 18th Annual American Business Awards®. Each year, the American Business Awards (also known as the Stevies) honor leading businesses and organizations for their excellence in a variety of industries. The winners are determined by the average scores of more than 230 professionals worldwide over a three-month judging process. For the second year running, Contentstack was chosen as a Gold Winner in the Content Management Solution category.

Contentstack is the pioneering API-first enterprise SaaS platform at the intersection of content management and digital experiences. The first headless CMS to enable business and IT to easily collaborate, Contentstack removes silos between business units and enables organizations to provide unparalleled customer experiences. In the past year, Contentstack has tripled business and announced $31.5 million in Series A funding led by Insight Partners.

The Stevies judges are executives from all over the United States, and they scored organizations on qualities such as innovation, integrity, effectiveness, creativity, and growth.

Some of the judges’ comments on Contentstack were:

“Delivers best in class integrations and easy access to business users to the key capabilities and drive content delivery across different channels and devices.”

“A great option to provide more opportunities for business owners to spread their valuable messages in a more efficient and effective way.”

“Delivering a unique digital content experience!”

This second Golden Stevie award comes on the heels of Contentstack’s recognition as a G2 Crowd favorite. Contentstack’s founder and CEO Neha Sampat was also honored with a Tech Trailblazer Award.

Although we at Contentstack are thrilled and humbled by these accolades, our greatest measure of success is how we empower customers, who trust us with their content management needs. Awards like these are meaningful because they are built on these relationships. Although Contentstack has grown by leaps and bounds over the past year, we have worked hard to provide outstanding service to customers new and old.

Contentstack is also in the running for the People’s Choice Stevie® Awards for Favorite New Products. Voting is now open to the general public, and you can vote for Contentstack until July 15, 2020.

About the Stevie Awards

Stevie Awards are conferred in seven programs: the Asia-Pacific Stevie Awards, the German Stevie Awards, The American Business Awards®, The International Business Awards®, the Stevie Awards for Women in Business, the Stevie Awards for Great Employers, and the Stevie Awards for Sales & Customer Service. Stevie Awards competitions receive more than 12,000 entries each year from organizations in more than 70 nations. Honoring organizations of all types and sizes and the people behind them, the Stevies recognize outstanding performances in the workplace worldwide. Learn more about the Stevie Awards at www.StevieAwards.com.