Developers
Learn how to build better digital experiences
Building a scalable DXP - Part 1
Scale is one of the most common and fundamental problems digital teams have to confront in order to grow their businesses. But more than just a key to unlocking growth, how a team thinks about scale can affect costs, ongoing resource capacity, feature roadmaps, and even an organization’s overall pace of innovation. In the universe of digital experience (DX), which spans all the way from the devices at the frontier of your audience’s senses all the way to the cloud and hardware that powers your company’s back-of-house operations, scale applies in some way to nearly every facet between these two ends. Understanding how the systems, people and processes that make up this end-to-end DX assembly line fit together and affect each other is key to unlocking that scale.This article aims to explain how to scale your digital experience platform (DXP). In it, we will discuss the meaning of scale, how to approach scale within your organization, and why it’s important. What exactly does it mean to scale?Simply put, scale is the relationship between the inputs and outputs of a given system. When people refer to scaling a business, they are typically talking about increasing outputs, like sales and revenue, while holding constant or decreasing inputs, like costs and materials. In an engineering-oriented team, scale often refers to hardware and software, such as the ability to flex or expand capacity to process more operations. If you work on a content or marketing team, scale usually refers to growing your audience, increasing engagement, and publishing more and better content. On the business and leadership teams, scale usually means increasing revenue.But these definitions of scale are oversimplified because they focus only on the outputs of these systems while ignoring the inputs. Or to put it another way, when we are talking only about increasing the outputs of a system, we’re talking about growth. When we talk about increasing outputs relative to the inputs, we are talking about scale.A “scalable” case studyConsider a digital agency as a hypothetical case study. The agency builds highly engaging promotional websites, and its revenue is directly tied to the number of websites it can implement for its customers. Let’s assume the agency is high touch and that each website takes a total of 1,000 hours to successfully design, build and launch. Let’s also assume that the agency employs 10 people, for a total of 20,000 available hours per year (ignoring PTO) and enough resources and the proper staffing configuration to successfully sell and deploy a maximum of 20 new sites per year.A blunt approach to scaling this business model would be to demand more than 20 sites out of the talent. In this approach, leadership sees the staff as the enemies of scale and demands more output from them in the form of working faster and staying late to meet aggressive goals. Indeed many companies attempt this strategy at the cost of talent attrition, sloppy work, constant training of new employees, missed deadlines and lost customers. Launching just two additional sites per year would require every employee to work an average of about one extra half-day every week of the year, leaving scant time for family as well as the occasional urgent customer support request.Another approach is hiring additional talent and slowly scaling up output while demand catches up to the newly increased capacity. Although this approach is common, it comes with the risk of increasing investment before increasing revenue, and when applied responsibly it can take some time to pay off. Leaders who choose this tactic will hire, say, two more staff with the aim of selling and launching about four additional sites per year. While this approach is intuitive, once the full cost of two FTEs, the opportunity costs of training them, and the revenue from four additional sites are factored into the balance sheet, it’s easy to see that this approach could be slow to take off and perhaps actually decrease the agency’s profit margin over time if it doesn’t go well.Now consider a third approach, where leadership recommends that each team looks for opportunities to repurpose generic work developed for other customers in order to reduce the number of hours required to implement new websites. Over the course of building the next few sites, the teams are able to develop reusable components of their work, for example, in the form of code and design libraries for commonly requested solutions, which in turn results in an average reduction of 200 hours across all website deliverables. This means that the agency can now produce 20 sites of the same or better quality in only 16,000 hours, which increases output capacity to 25 websites in the same original 20,000 available hours without adding staff or increasing costs.Scale smarter, not harderWhile each of these three examples are strategies for how an agency might approach scaling up output, the third example is a clear frontrunner because it has the highest impact on increasing output while at the same time holding inputs relatively constant. The third approach is also the only example out of the three that can lead to economies of scale. Economies of scale describe the state of a relationship between an input, such as cost per unit, and an output, say, the number of units produced, where the cost per unit actually goes down as you create more units. This relationship between inputs and outputs is what people typically mean when they say they want to scale something. It is not just that they want outputs to grow, but that they want outputs to grow and the cost of inputs to stay flat or decrease at the same time.Although this case study centers around an agency and looks at three simplified approaches to scaling the overall business outputs, it’s useful to shed light on the fundamental concepts of scale before unpacking the specifics of scaling a DXP. Here we’ve highlighted two essential tenets that will benefit digital leaders as they work to scale nearly any system: There are many ways to approach a problem of scale, some sustainable and some unsustainable. Scaling on the backs of employees, for instance, is not a sustainable approach. There is nothing wrong with hustling to achieve a goal, but hustle alone lacks the strategic thinking that unlocks scale, which leads us to our second tenet.Effective and durable scaling centers around creativity and is founded upon understanding — not brute force. But don’t be discouraged if you feel you or your team lacks creativity or your processes are too complex for anyone to understand. As we will see in the following articles, there are some tried and true methods for creating the conditions for creativity to emerge, and if you apply them with your teams you will have a higher likelihood of successfully achieving scale, no matter what it is you wish to scale.What’s next? Now that we’ve established a baseline understanding of scale, in Part 2 we will set the agency example aside and explore specifically what it means to scale a DXP. Stay tuned!About the authorDean Haddock is a Senior Product Manager at Contentstack who focuses on platform, hosting and data engineering.Learn more about Dean
Headless commerce vs. composable: What you need to know
The online world is constantly evolving, so companies must change how they work and develop new ideas to meet customers' changing needs. The e-commerce sector has witnessed the rise of two unique models: headless commerce and composable commerce. While they might appear similar at the outset, a deeper examination reveals critical distinctions.In this article, we'll demystify the two approaches, spotlight their respective pros and cons. And provide insights for organizations pondering a transition to a composable architecture.How headless commerce beganIn the early days of online shopping, businesses had two ways to sell their products: physical stores and online platforms. But as technology advanced, many companies didn't keep up with the changes. This made it hard for them to stay up with what customers wanted and take advantage of new trends. The problem was that their technology wasn't flexible enough to adapt to new ideas.To serve customers better, stores began separating their online behind-the-scenes system from what the public sees on their websites. They did this by using APIs to access the back end, which made their operations more flexible.Headless commerce is a way for brands to keep their complicated commerce systems while making the front end more flexible to changes in the market.Composable architecture means that each part of the system works independently and can be customized to fit a brand's specific needs. This gives businesses the power to choose which parts of their digital services to use to meet their unique business requirements best.Examining headless commerce architectureHeadless is a new way of handling e-commerce that separates the parts that users see (the interface) from the parts that do the work behind the scenes (data, operations, applications). Most e-commerce systems combine these two parts, making it hard to keep up with the constantly changing digital market. Headless, by contrast, allows the front- and back-end systems to function independently. Benefits of headless architectureAdopting a headless system introduces several advantages:It delivers a flexible and customizable front end. With the visual layer decoupled, developers are no longer tied to the constraints of the back end, allowing for the creation of custom user experiences. It enables seamless integration with other systems. The back end operates independently, communicating simultaneously with multiple front ends. This allows businesses to provide a consistent omnichannel experience across various platforms like websites, mobile apps, smartwatches, and IoT devices. For instance, should a brand face difficulties in producing content for new products due to the constraints of its content model, the headless commerce system allows the integration of a different content management system with adjustable content models. This flexibility ensures a smoother operation by effectively mitigating the identified issue.It accelerates the speed of innovation. Changes to the front end won't impact the back end, and vice versa. This promotes quicker updates, experiments and iterations, all critical components in today's fast-paced digital landscape.Drawbacks of headless architectureWhile headless offers clear benefits, it also carries some drawbacks:This way of setting up a system can be challenging to handle. It needs someone with technical knowledge to take care of the different parts and keep them working.While the freedom to customize front-end interfaces is a benefit, it also means that businesses are responsible for designing and developing these interfaces, which can be time-consuming and costly.Depending on the chosen system, limited support or functionalities may be available.Understanding composable architectureComposable is an approach to building digital services that allows each component to exist independently. This includes things like managing product information, content and customer relationships. Businesses can choose which parts they need to create a custom digital platform.Advantages of composable architectureComposable e-commerce offers significant advantages.It provides extreme flexibility. Since all components are separate, they can be independently updated, replaced or reconfigured, enabling a truly agile e-commerce platform. This architecture allows for continuous optimization without fear of disrupting the entire system.Composable future-proofs your DXP stack by implementing task-oriented packaged business capabilities (PBCs), which are essential for faster time to market and better adoption of a digital experience. With the ability to add or replace components as needed, businesses can keep pace with technological advancements, customer demands or changes in business strategy.It promotes the best-of-breed approach. Businesses are no longer confined to the capabilities of a single vendor. They can select the best software for each component, maximizing functionality, efficiency and performance.Pivoting toward composable architecture: Points to ponderEmbracing composable commerce vs. headless architecture is a significant decision you should not take lightly. Businesses should thoroughly analyze their current and future needs, evaluating whether the flexibility and adaptability of composable commerce align with their strategic goals.The appeal of composable architecture lies in its flexibility and potential for success. However, it's important to remember that just because something is possible doesn't mean it's a good idea. Composable architecture can be compared to Lego blocks, as it allows for the creation of many different structures. But the challenge lies in deciding what to build and how to make it happen.The challenge is twofold. First, there's the job of putting together all the components. Second, it's essential to ensure that each element chosen is not just a fun extra but helps create the desired digital experience is essential. It's crucial to tell the difference between the "must-have" and "nice-to-have" features. Focusing too much on the latter can take away your IT team's attention and resources from the essential functions.It's important to think about how much technical knowledge is needed. Composable gives you a lot of choices for customization. Still, it takes a skilled technical team to handle everything and ensure it works well. If you're thinking about using composable, you should ensure you have the right resources or get help from experts to make it easier.Additionally, companies must evaluate their current system's limitations. Are you finding it challenging to innovate due to a rigid, tightly coupled e-commerce platform? Does your business plan to expand into new channels or markets that your current platform cannot support? These pivotal questions can help determine if the transition to composable is warranted.When picking technology partners, it's crucial for organizations to choose carefully. The best partners will offer a variety of components that can be easily swapped out and will provide support and updates over time. The goal is to create an e-commerce platform that can grow and change as the business and customers do.Learn moreLearn more about transitioning to composable in this episode of "Contentstack LIVE!" featuring Contentstack Vice President of Technical Services Pete Larsen.Schedule a free demo to see how Contentstack's composable digital experience platform can help your organization achieve its e-commerce goals.
The beauty of a composable digital experience platform: It can be whatever you need
Have you ever tried designing a website from a template? It can be challenging. First, there are so many options to scroll through (that all somehow look the same) your head will spin. When you do pick a template, you have to build it the way you want, meaning a lot of customization. When that doesn’t work — because inevitably, you always hit the end of what the template can offer — you have to puzzle your way through custom code. That can become a tangled web very quickly.Imagine that process for an established enterprise like Sephora or even a fast-growing start-up. Think about the manual process of integrating each tool needed for e-commerce or inventory management. You think you are “done” building, but wait — the market is evolving and you need to start selling on a new-ish platform like TikTok or BeReal.A traditional legacy CMS environment is tricky: Change one thing and you risk the entire machine stalling. The beauty of composable architecture is that your website can become whatever you want, whenever you need it — easily. Jurre van Ruth, digital strategy consultant at PostNL, came on our podcast, “People Changing Enterprises,” to discuss how the company took that concept to heart and made their composable DXP work for them. But to make it work for your company like PostNL did, we need to level-set definitions and expectations. There’s a lot of confusion in the market about composable architectures — like what is a “composable DXP” in the first place — that I want to clear up. What is a composable DXP?I like how van Ruth said it in the podcast: “We see [composable] as an ecosystem of technologies that aim to create and offer a consistent digital experience for all our customer segments across all digital touchpoints.” I specifically love the word "ecosystem" he uses. CMSWire describes a composable DXP as providing “integrated, consistent solutions that are modular and tailored to microservices and yet connect the gaps of digital experience. This is a unified and seamless approach that eliminates siloed user experiences and all-in-one solutions.”To further flesh out that picture, I often describe composable architecture as a Lego tower: Each block is a tech tool and they each function together to make up one, larger tower, aka the customer’s digital experience. However, unlike a sculpture — or legacy enterprise suites — you can more easily change the look and function of the entire tower by swapping out each block within. For example, if your next marketing goal is to target potential consumers with more personalized advertising and content, those tools are easier to plug into a composable environment than traditional suites. Creative teams get to pursue the digital experience platform of their dreams, and there is much less frustration, less custom code and fewer heavy integration requirements for IT to handle on the back end.Then where does headless — AKA a headless CMS like Contentstack — come in? It’s simply a cornerstone block in your Lego tower. For a marketing environment, the headless CMS acts as a foundation. Every tool — like e-commerce, automated translation, or SEO tools — can integrate into it to make content the central hub of your ecosystem.Moving beyond one-size-fits-allEvery enterprise is different, which means that the capabilities they need will also be different. However, when it comes to traditional legacy martech systems, it tends to be one-size-fits-all. The problem is that one size actually doesn’t fit all, and those environments are slow and difficult to change. It takes extreme customization via code, contacting multiple vendors for help, and a lot of inter-dependencies that aren’t always caught until something breaks. One of the best benefits of composable is that integration is much easier and more natural with APIs inherent to a composable environment. Like clicking a Lego into place, that tool is now part of the environment. For PostNL, they invested in tools for headless content and digital experience analytics, which were easily plugged into their composable environment.An e-commerce enterprise can integrate all the tools they require, whether it’s an online storefront platform, a product catalog with elements like descriptions or visual assets, or any personalization tools it might need. But, for example, a hospitality service will need a different set of tools, and they can have them inside a composable environment.Enterprises are no longer satisfied with a one-size-fits-all approach. The beauty of composable architectures is that, in a market that changes like the wind, organizations’ digital experiences can also evolve just as easily.
3 ways tech and business teams can help each other through a transformation
Not all great tech transformations are brought to the table by a developer, engineer, CTO or other technical person. We see great projects kick off because someone in marketing, sales or customer success raises the flag for change. Sometimes business people can see opportunities that aren’t as plain to the tech teams.That’s what happened when Booking.com decided to transition off its old systems to a headless CMS. Juliette Olah, senior manager of Editorial, realized that her teams had produced thousands of pieces of content over the years — but the capabilities of their current technology significantly limited the value that content produced in their local markets and possibilities for the future.Listening to her “People Changing Enterprises” episodes, I admired the way Juliette united Booking.com’s product and editorial teams from the beginning to pull off their transformation. Business and tech can either be each other’s biggest advocates or frustrating roadblocks.To avoid the latter, these are three examples of how tech and business teams can support each other throughout a transformation.Thoroughly debrief at the onsetAt the beginning of every project, we encourage organizations to sit down with their cross-functional teams and level set. Business and tech have their own KPIs and goals to achieve. In a project that bridges the two, there should be a frank discussion, ending in clear, written requirements of process and goals for both sides.Once Juliette realized a tech transformation was the answer to the editorial team’s needs, she became the living bridge between the editorial and product teams. Sitting down with tech stakeholders, they talked through what Juliette called a “comprehensive 360 view of the benefits to the technical side of the platform”:The editorial team’s strategy and the justification behind the new technologyReal-life examples of what execution would look likeThe business value of a central headless CMS would bring to each local marketOpportunities they were currently missing out on because of their current toolBecause she had clearly done her homework and demonstrated the need on both sides, the product team was eager to get started.Partner up to find and test new toolsFinding and testing new tools is an easy way for business and tech teams to partner effectively. When the new CMS was in place, the teams at Booking.com partnered to try out the new tool to make sure it worked for both sides.At Contentstack, once a new solution is initially developed, we pull in our business partners for User Acceptance Testing. They can test, catch bugs, or point out which workflows function trickier than anticipated — versus the tech teams doing it all themselves.Additionally, when you’re on the hunt for new tools, tag a business partner in for their opinion. From a different mindset, they might be able to raise questions or point out benefits you didn’t consider. Work together to phase out what isn’t neededA transition to composable is the perfect time to evaluate what tools you’re bringing into the new environment — and which ones you should retire. This is another area that tech and business teams should work together.A few years ago, we bought an analytics tool for the organization to use on their reports. It was low-cost and met some of our needs upfront, so we decided to take a chance on it. Six months down the road, we were spending a huge amount of time trying to force the tool to work. When a business person came to me and admitted the tool wasn’t helping their team meet their objectives, we decided to look into something else. On a composable project, it’s not always clear on the back end if a tool is working for teams as they need. That’s where our business partners come in. It’s a partnership.Babe Ruth once said, "The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime."It’s easy for business and tech teams to work in silos, but working together produces more value. Especially in a tech transformation, the two teams are different sides of one coin. Find ways to bridge the gap and you’ll see much more value in your resulting tech stack.
Bridging monolith and composable with automation, with Director of Engineering Keith Mazanec
Moving to composable technology almost never happens all at once. There is a transition period. How do you help teams make the most of the composable technology, while easing the transition between old and new? Keith Mazanec, Director of Software Engineering at Brad’s Deals shares how they used a composable content technology with automation capabilities (Contentstack) to create an easy transition that improved the lives of content editors straightaway - and created a better experience for everyone, customers included. Plus, hear about their favorite uses of Automation Hub to automate across the content lifecycle.Timestamps:1:05 The volume of content at Brad's Deals, and what that means for content editors1:56 Why Brad's Deals looked for a new content management technology2:27 An example of how automations helped reduce manual data entry for content editors3:57 The custom dashboard Brad's Deals built for their editors5:06 Example of automating a categorizing function to speed up content publishing process6:03 Versioning and automating making changes to the content model8:16 How Brad's Deals created continuity between their legacy technology and the new headless CMS9:57 Automating throughout the content lifecycle across different content & marketing applications
How switching to a composable DXP will affect security
The top priority for any business is protecting sensitive information from cyberattacks, and the effectiveness of your cybersecurity measures largely depends on your tech stack. There are a number of benefits of going composable, and a key one is that composable DXPs can offer better security than monolithic solutions. Read on to learn: How going composable can improve your organization’s cybersecurity What you need to know to make your composable tech stack as secure as possible What is composable architecture? Composable architecture breaks down the large and complex functions found in monolithic solutions into smaller, more manageable pieces. An API acts as the go-between for these smaller pieces, allowing them to communicate and transfer information more efficiently. In a composable CMS, the front-end and back-end layers are decoupled, so changes can be made to the front end independent of back-end functions. There are a variety of benefits of moving to a composable DXP, including reduced IT costs, more streamlined processes and functions, easier updates and, when properly implemented, better security. What are the biggest threats businesses face? Cyberattacks have always posed a risk to businesses, but that threat has grown in the past decade. Businesses have beefed up their cybersecurity measures when it comes to some of the more common threats like phishing and malware; unfortunately, hackers have responded by developing more sophisticated cyberattacks that are harder to spot — and more difficult to guard against. Today, businesses face a slew of cybersecurity threats. Ransomware attacks hold entire networks hostage. Endpoint attacks are on the rise, thanks to the shift toward remote work and, in turn, the number of off-site Internet of Things (IoT) devices connected to business systems. Supply chain attacks exploit security weaknesses in third-party vendors or providers to gain access to their partners’ systems. And even though we are better trained to spot phishing attempts and avoid malware, these strategies still work often enough that hackers continue to use them. Composable DXPs provide the flexibility to employ cutting-edge cybersecurity measures to protect against cyber attacks and data breaches. The security benefits of going composable A strong cybersecurity strategy is especially important with composable DXPs. As noted above, a composable approach offers the ability to break the large, single-suite functions of monolithic platforms into smaller components. This allows for more customization options, as organizations can pick and choose the specific programs and functions they need to deliver a top-tier digital experience. But each individual piece has its own security requirements and vulnerabilities, and your cybersecurity strategy needs to account for all these differences so there are no holes to exploit. When moving to a composable DXP, a key first step is to define your security needs and identify the security tech stack that best meets those needs. This will serve as the foundation of your cybersecurity framework, and all the functionality that follows needs to fit within it. The benefit is that it makes it much easier to identify and isolate any vulnerabilities in your security. With monolithic systems, spotting security risks or finding the source of a breach means combing through the entire system. With a composable DXP, it’s much faster and easier to go through each individual function and make the necessary adjustments to secure your system. How to properly secure your composable tech stack Breaking out functions into individual components with a composable DXP solution creates more endpoints that can be vulnerable to cyberattacks. But even though there are more potential points of access, there are also more ways to secure your systems. API management platforms make it easy to track API usage and integrate up-to-date security protocols like OAuth and OpenID. That allows you to control who can access and use critical applications and data stored in cloud services, and with authentication processes to verify user IDs, you can catch any security threats before a breach occurs. To secure your composable DXP, these functions are essential: End-to-end encryption Access controls Authentication: Encryption keys; 2FA; securing IoT devices Data protection Detailed monitoring Implementing these functions and tailoring them to the unique needs of your composable DXP helps ensure that the sensitive data in your platform is protected from cyberattacks. Data security in your composable DXP When it comes to brand interactions, today’s consumer expects a personalized experience, but in order to create a robust customer journey, you need to gather data about your customers. Consumers are willing to provide that data if it means a better digital experience — but they also expect that their sensitive information will be safe in your hands. The financial cost of a data breach can be massive, but it’s nothing compared to the damage your organization’s reputation will suffer if your customer data is exposed due to a security breach. Fortunately, your composable DXP strategies can help provide better data security. With a monolithic system, if your critical infrastructure is breached, all your customer data is exposed. A composable DXP allows you to create modular data pipelines that connect to each individual component and the relevant data, rather than a single large block that contains all your data, as is the case with legacy systems. With composable, you can scale up or down and implement or remove components based on your security needs. And if a data breach does occur in one component, the scope of the data exposure is usually limited. Securely meeting consumer demands The customer experience is delivered across different parts of your composable DXP, from your headless CMS to your marketing stack — and it all needs to be supported by a robust cybersecurity strategy that meets or exceeds industry standards. Cybersecurity threats come in all shapes and sizes, and cyberattacks can come from anywhere. To combat those threats and protect your system, your cybersecurity strategy needs to address all the potential risks. Your technology also needs to be flexible and adaptable in order to guard against new threats as they arise. Going composable allows you to build your tech stack to match your security strategy, and vice versa. It’s important to remember that ensuring a safe and secure experience goes beyond adding security protocols to your tech stack. Rather, it’s about deploying the right technologies and data protection programs and practices for the unique needs of your organization. Learn more Learn more about composable architecture in our blog post, “Why composable architecture is the future of digital experience.” Schedule a free demo to learn how Contentstack can help you create a secure composable DXP solution that best suits your organization’s needs.
From legacy systems to microservices: Transforming auth architecture
Contentstack receives billions of API requests daily, and every request must be validated to be a valid Contentstack identity. It is a common industry practice to achieve this using some sort of “identity token" for every request. Imagine having multiple types of identity tokens, such as session tokens, OAuth tokens, delivery tokens, management tokens, etc. The problem of securing billions of API requests daily can be challenging. We decided to address this by spinning up a new team that handles the complex problems of user authentication and authorization in a token-agnostic platform.Our transition journey Contentstack started as an API-first headless CMS platform that allowed content managers to create and manage content while simultaneously and independently enabling developers to use Contentstack's delivery API to pull that content and render it to create websites and applications. This means that Contentstack’s traffic increases proportionately to the traffic received by our customers' websites and applications.With increased traffic and usage, we catered to various new use cases by developing new features. These features were powered by a set of microservices, each catering to a particular feature domain and needing support for processing multiple identity tokens that had roles and permissions associated with them. The whole system had turned out to be quite complex, and performing auth had become a great challenge. This prompted us to redesign our auth architecture, which addressed the issues of being a token-agnostic and low-latency platform.Read on to learn more about this journey and how we have been able to:Transition from a monolith to a low latency microservices-based auth (authentication plus authorization) and rate-limiting architecture.Set up centralized authentication for multiple (any domain) microservices that are part of the same Kubernetes cluster.Set up decentralized and self-serviced, policy-based authorization for internal services and teams.Increasing feature sets increased domain microservices, which increased the complexity of performing auth.Monolithic auth architectureMonolithic architectures can be difficult to maintain, scale and deploy. In a monolithic architecture, user authentication and authorization are typically tightly coupled with the application code, making it difficult to implement and maintain robust security measures. Monolithic architectures often rely on a single authentication and authorization mechanism for the entire application, which can limit the flexibility of the system to accommodate different types of users or access levels.Performing auth in a typical monolithic architecture.In monolithic architectures, the steps involved in auth are the following:Users use their credentials at the client to generate a session token or use an existing identity token to generate other identity tokens.Users then use the generated identity token to perform a business operation by making a request to the application server.Once a request is received at the application server, the authentication middleware authenticates the token and forwards the request to the business module.The business module performs the business operation based on the authorization rules applied to the user identity.Problems with monolithic auth architecture:Authentication and authorization logic is mixed with the business logic.Changing the way an identity performs an operation on a resource involves a change in the associated auth-related logic.Each domain individually implements the authorization logic, causing a difference in implementation.Since authorization logic is deeply nested in business logic, we lack visibility into authorization rules applied to a resource.Shipping of new authorization logic requires a fresh deployment of the application image.New microservices require knowledge of various identity tokens and resource authorization rules to be applied.Microservices auth architectureMicroservices offer a more flexible, modular approach that allows for easier maintenance, scalability and deployment. With microservices, each service can be developed, deployed and scaled independently, allowing for faster time-to-market, improved fault tolerance, and better alignment with modern development practices. Additionally, microservices offer more efficient use of resources and better support for diverse technology stacks.AuthenticationWhy centralized authentication?Centralized authentication is a security model in which a central authority manages authentication, such as a server or service, rather than it being distributed across multiple systems or applications. There are several reasons why centralized authentication is commonly used and considered advantageous, including increased security, simplified management, improved user experience and lower costs. While there are some drawbacks to centralized authentication, such as the increased risk of a single point of failure and increased complexity in managing the central authority, the benefits often outweigh the risks. Centralized authentication and rate-limiting at the edge of the service mesh.The steps involved in the centralized authentication process are the following:Any incoming request to the Kubernetes cluster first lands at the Istio ingress gateway.The request containing the identity token is proxied to a central authentication gRPC service with the help of envoyproxy's external authorization filter.The central authentication service queries Redis with the identity token and metadata associated with the request.Redis responds with the identity associated with the token and the current rate-limit count based on the request metadata.The central authentication service responds to Istio with either of the following:Authenticated response with user context attached to the request in the form of request headersUnauthenticated responseRatelimit exceeded responseAn authenticated request containing the user context is then forwarded to the upstream service.Advantages over the monolithic architecture:Easier to onboard newer microservices to central authentication service by using label based istio-injection.All requests are authenticated and rate-limited at the edge of the service mesh, ensuring that each request entering the cluster is always rate-limited and authenticated.The request forwarded to the upstream microservice has user identity context attached to it in the request headers, which can be further used for applying authorization rules.Keeping centralized authentication eliminates the problem of multiple mutations performed by the upstream microservices on the identity of the token.Authorization Centralized authorizationWe tried a model where along with authentication and rate limiting, we also added authorization as a responsibility of the central authentication and rate limiting service. The service would first identify the incoming request’s identity from the token and apply rate limiting based on the request metadata. Once the user identity is known, authorization rules could be applied to the user’s identity, thereby performing the entire Auth at the edge of the service mesh. Problems with this model are the following:This model could only perform basic authorization at the edge based on the request metadata provided, such as validating organizations, stacks, etc. However, it could not perform fine-grained authorization, such as finding out which content types the logged-in user had access to.For RBAC, each domain has its roles and permissions associated with it; performing authorization for such requests requires knowledge of the upstream domain and leads to the addition of domain-specific logic in the centrally managed domain-agnostic platform.With newer domain microservice additions, this again would lead to the problem of lacking visibility into authorization rules applied to a resource.Distributed authorization with central authorization serviceWe then tried implementing a model where we distributed authorization to the upstream microservices where each upstream microservice makes a call to a central authorization service. The authorization service has access to all the roles and permissions of different domains and was able to give appropriate authorization results. Authorization could now be performed from the upstream service’s business module by making a network request using Kubernetes cluster networking to avoid making a call over the internet.Problems with this model are the following:The central authorization service becomes a single point of failure.Any change in the API contract defined by the central authorization service requires all the upstream services to abide by it and makes shipping these changes independently a complex task.Performing authorization adds a network hop, thereby increasing the latency.Distributed authorization with the sidecar patternLearning from the previously discussed disadvantages, we wanted to build a model that had authorization distributed, low latency and made shipping authorization logic an independent activity. ArchitectureThe architecture involves the following components:Auth sidecarCentral policy serviceAuth SDKArchitecture for authorizing an authenticated request with the sidecar pattern.Auth sidecarThe auth sidecar is a gRPC service that gets injected along with the microservice’s application container in the same Kubernetes pod. Let’s understand how this architecture helped us tackle the previously mentioned problems.Single point of failure: The auth sidecar service runs with the application container in the same pod, and any case of failure is only limited to the current pod. Restarting the pod gives us a fresh set of application and auth sidecar containers.Independent delivery: Since the auth sidecar service container is shipped along with the application container, the application service can decide which version of the sidecar image to use, thereby making the delivery of newer versions of the authorization sidecar independent.Low latency: There is no network hop involved in making a gRPC call to the auth sidecar running in the same pod. This helps the application to get the authorization result with very low latency (in a few milliseconds).Updating authorization logic: The auth sidecar periodically downloads fresh policy bundles; any time there is a change in policy bundle coming from the central policy service, the auth sidecar updates its local policy cache with the new bundle.This way, updating authorization logic does not involve a fresh deployment/restart of the application container.Components involved in auth sidecar Responsibilities of the components involved in the authorization sidecar.Aggregator: The responsibility of the aggregator is to fetch authorization-related data for the current identity based on the metadata provided by the application service in the gRPC call. It then aggregates it to be evaluated against the authorization policy.OPA Engine: We use OPA (Open Policy Agent) to periodically download fresh policies and evaluate the policy path mentioned in the gRPC call against the aggregated data.Central policy serviceThe central policy service is a repository of policy bundles (*.rego files) which are independently managed by the domain microservices. The maintainers of the domain microservices create these policies for various resources that need authorization. Since these policies only involve rules, it greatly increases the visibility of authorization rules being applied to a particular resource.Auth SDKThe auth-sdk is an internal library that we developed that helps the developers of upstream microservices to easily communicate with different auth components. It can do the following:Extract user identity and other useful information attached in the request headers by the central authentication serviceDiscover various auth components and streamline communicating with themExpose different helper methods to perform any auth-related activity on behalf of the application serviceRedesigned (new) architecture:Tracing the request lifecycle in our redesigned auth architecture.ConclusionMicroservices-based architectures can help address some of these challenges of monolithic architecture by separating user authentication and authorization into individual services, which can be developed, deployed and maintained independently. This approach can provide greater flexibility, scalability and security for user authentication and authorization.However, it's important to note that transitioning to a microservices-based architecture can also come with some challenges, such as increased complexity and a need for more advanced DevOps practices. Proper planning, implementation and ongoing maintenance are crucial to ensuring a successful transition.
How to make the most of your composable DXP with ChatGPT
ChatGPT has gotten plenty of attention in recent months. The chatbot, developed by OpenAI, recently made headlines for (among other things) passing law exams, a Wharton business management exam, and parts of the US Medical Licensing Exam, all without any external input. ChatGPT reached 1 million users within five days of release; by comparison, it took Spotify five months to reach that threshold. For digital brands, the arrival of ChatGPT is a game-changer — especially when it comes to creating content and content management. Read on to learn how to use ChatGPT with a composable DXP.What is ChatGPT?ChatGPT is a natural language processing tool powered by AI technology. Using reams of text from the open internet, the program is asked to predict the next word in a text string, over and over. Over the course of trillions of predictions, GPT has learned not just how to predict the next word, but also use its training data to answer questions and complete tasks assigned to it. As you can imagine, this presents a lot of opportunities for brands to enhance their digital experience platforms.How can ChatGPT integrate with a composable CMS?Although ChatGPT was not designed specifically to work with content management systems, there are ways to integrate it into your CMS and leverage its capabilities to improve the digital experience.Chatbot engineWith most chatbots, user communication is on rails. Standard chatbots only recognize specific prompts, and depending on how the chatbot is designed, those prompts might not cover everything users may need. ChatGPT is able to have real, natural conversations with users for a more robust and personalized experience. Using ChatGPT as the conversational engine for the chatbot, the CMS can use relevant content — such as articles, FAQs, product information, and more — as training data, which ChatGPT can then use to answer user queries. ChatGPT can also enhance the chatbot's ability to understand and respond to natural language queries, so users can ask questions however they want and still get the answer they’re looking for. The benefit for your team is less time spent designing the chatbot to respond to every possible user query (and every possible variation of those queries). ChatGPT can also connect to your CMS via custom API integration. When users interact with your CMS, the web service can run the user’s query through ChatGPT, and ChatGPT’s response can then be returned to the web service to be displayed to users. Whether you use ChatGPT to power a chatbot or integrate it with your CMS, users benefit from a more engaging and personalized experience — and your customer support team benefits from the automation of some of their more time-intensive tasks.Marketing automation and personalizationGood marketing is informative. Great marketing is informative and has a personal touch. Generic or broad automated marketing is unlikely to win new customers; instead, your marketing needs to address each user’s unique preferences in order to win their business. Unfortunately, creating highly specific content that speaks to each individual user is incredibly time-consuming. ChatGPT can take information about your customers’ interests, preferences and behaviors and use it as training data to create more personalized and targeted marketing content in a fraction of the time. In other words, brands don’t have to choose between reach and personalization — ChatGPT can provide both.Coding suggestions for front-end and back-end developmentReviewing code is a necessary part of updating and enhancing your composable digital experience platform, but it can be a major time and resource drain for your DevOps team. Since ChatGPT is a language model, it can read and understand code written in a variety of programming languages — which can save you time and stress as you prepare to roll out new features or functions on your platform.Strictly speaking, ChatGPT is not able to “review” code in the way a developer would, because ChatGPT doesn’t understand the context of the code the way a human developer does. Still, ChatGPT can answer specific programming questions for developers, review code syntax and point out any potential logical flaws in the code that can save time on debugging. Content creation and testingEffective content helps attract new users to your site and delivers a quality experience that will encourage repeat visits. Producing high-quality content requires a lot of time, effort and resources. ChatGPT can handle many of the tasks that might otherwise require you to hire a team of writers or content specialists.ChatGPT’s role in content creation is entirely up to you and your needs. You can use ChatGPT to generate content ideas by providing prompts and suggestions related to your business and letting ChatGPT suggest topics that will resonate with your target audience. ChatGPT can also be used to test existing content: Simply provide the AI model with existing pieces of content and ask for suggestions, and ChatGPT will offer suggestions to make the content more engaging, more informative or more SEO-friendly. On the other end of the spectrum, ChatGPT can also be used to create outlines or even entire pieces of content from scratch. With a bit of guidance in the form of prompts or content topics, ChatGPT can write full articles and blog posts, which can then be edited and customized to match your brand’s voice and messaging. It’s important to note, however, that while ChatGPT can drastically reduce the amount of time spent on content creation, there is still value in a human element. Users may eventually learn to spot AI-generated content, and your SEO can suffer if your content bears too many AI fingerprints. When used effectively, ChatGPT can help reduce the time your team spends on content creation and the tedious tasks that go with it.How Contentstack AI Assistant leverages the power of ChatGPTContent creation is a crucial part of building a connection with your audience, and ChatGPT is poised to transform the content creation and publishing experience. The new Contentstack AI Assistant harnesses the power of ChatGPT to help teams create brand-specific content in seconds. By adding ChatGPT to your entry editor through in-line UI extensions, the Contentstack AI Assistant makes it easy for content teams to leverage ChatGPT’s capabilities however they choose. Want to experiment with content creation? Quickly and easily build outlines for content writers? Create summaries, outlines, metadata tags, and headlines so editors and publishers can move on to other tasks? Translate content for global users? All this (and much more) is possible with just a single prompt to the Contentstack AI Assistant. The possibilities for your content are endless. With Contentstack AI Assistant, it’s never been easier to tap into those possibilities to take your content to a whole new level and get the most from your composable DXP. Learn moreWatch this episode of "Contentstack LIVE” with Contentstack VP of Product Conor Egan to learn more about the power of generative AI.Schedule a free demo to see how Contentstack can help you leverage the power of automation to launch digital experiences at the speed of your imagination.
What developers should know about composable DXPs
As enterprises strive to create a unified digital experience for their customers, it is essential to understand the fundamentals of composable DXPs. This blog post will explain what these platforms are, how they work, and how they can help create an effective customer experience. What is a composable DXP? A composable DXP (digital experience platform) is a technology stack that supports the development and deployment of applications across various channels such as web, mobile, voice assistants, wearables and more. It consists of different components such as content management systems (CMSes), microservices architecture, APIs, analytics tools, customer data platforms (CDPs), marketing automation tools and more. These components work together to enable developers to rapidly build and deploy applications with minimum effort. How does it work?The key to making a composable DXP successful is having the right components in place. Components of a composable DXP include:A CMS that is the foundation for managing content across multiple channels APIs that provide access to data stored in other systems such as databases or cloud services. Microservices architecture that helps break down large applications into smaller services that can be deployed independently. Analytics tools that allow developers to gain insights into user behaviorMarketing automation tools help automate tasks such as sending emails or messages on social media platformsA customer data platform to store customer data securely and easily access it when neededBenefits of adopting a composable DXPUsing a composable DXP has several benefits for developers including:Increased agility: With a composable DXP in place, developers can quickly build apps without spending time on coding from scratch or integrating multiple technologies together. This increases agility by allowing them to respond quickly to market needs or changes in customer preferences. Scalability: Composable DXPs are highly scalable so they can handle large amounts of traffic without compromising performance or reliability.Cost savings: Using a single platform reduces costs by eliminating the need for multiple technologies and license fees associated with them. Challenges for developersIntegrating multiple components One of the biggest challenges with composing a DXP is integrating all the different components together in a way that works seamlessly with each other. This requires extensive knowledge of web technologies, coding best practices, and design principles. It also requires developers to have an understanding of how different software interacts with each other and how they can be integrated into a single platform. Additionally, if there are any compatibility issues between two components or systems, then the developer will need to find a workaround or replace one component with another. Maintaining quality standards Another challenge that developers face when implementing a composable DXP is maintaining quality standards throughout the process. Since they are dealing with multiple pieces of software that may come from various sources, it’s important to ensure that all components meet certain quality standards before they can be used in production. This means making sure that all code is up-to-date and bug-free; all third-party APIs are secure; and all data sources have been tested for accuracy and completeness before being integrated into the platform. Testing for performance issues Finally, when creating a composable DXP, developers must also test for potential performance issues. As more components are added to the platform, there is an increased likelihood that some parts may not perform as expected due to memory usage or runtime errors. Therefore, it’s important for developers to thoroughly test their composable DXP before launching it in production to ensure its stability and eliminate any potential issues from arising later on down the line. ConclusionImplementing a composable DXP offers many advantages over traditional monolithic applications but comes with its own set of challenges. Developers must make sure each component functions properly and meets quality standards before being implemented into the system. They must also test their platform for potential performance issues before launch. You can overcome these challenges by carefully planning your architecture and understanding how each component integrates with one another so you can create an effective solution for your customers’ needs.Learn moreLearn more about going composable in our guide, “How to go composable in 6 steps.”Schedule a free demo to see how Contentstack's composable content experience platform can help your organization benefit from the flexibility and scalability of a composable DXP.
Composable vs. monolithic: Which is right for you?
Businesses are trying to create better customer experiences, so composable digital experience platforms (DXPs) are becoming more popular. But what are they? How do they compare to monolithic platforms? And how do you choose the right one for your business? In this blog post, we will answer these questions and more.What is a digital experience platform (DXP)?Digital experience platforms (DXP) are purpose-built technology solutions for creating, managing, delivering and optimizing consistent digital experiences across different customer touchpoints. These tools offer businesses a valuable way to communicate with their users through content and obtain customer feedback through data collection.Companies can utilize DXPs to create content tailored to websites, email campaigns, mobile apps, social media channels, e-commerce sites, IoT devices, digital signage systems and more. Beyond simply broadcasting content on each platform, DXPs also allow marketers to automate marketing activities and develop a unified digital experience that can take users toward their desired goals or objectives.DXPs help companies understand what customers want and need. They can do this by looking at how customers act online on websites, social media, and other online places. Businesses can then use this information to reach out in new ways or to improve their relationships with existing customers. Ultimately, using a DXP helps organizations make more sales or conversions by providing a better user experience across multiple channels.What is composable architecture?Composable architecture is an innovative way of organizing and managing software development that separates front-end and back-end code. This technique enables teams to create, modify and launch content without relying on developers for coding. This method of organization helps speed up development and make it more efficient. Composable architecture makes developing software easier while encouraging teamwork between different departments. For example, if you use a composable content management system, the marketing team can make changes and publish their work without waiting for developers to finish coding. This way, teams can post new content more quickly. Additionally, developers can focus on creating unique experiences and features instead of being bogged down with marketing tasks or fixes.What is a monolithic DXP?A monolithic DXP solution is an all-in-one platform that provides a suite of tools for managing content. These platforms are designed to enable users to store, manage and publish content quickly and easily. They typically offer features such as content editing options, user permissions and roles and media asset management.Monolithic content management solution platforms can be rigid in terms of how they operate and may not be able to keep up with the ever-changing needs of a business. Additionally, they tend to take longer to customize than composable DXP systems.What is a composable DXP?The composable DXP concept is still relatively new and has become increasingly popular recently. A composable DXP is a platform that allows digital teams to assemble individual services or microservices into an experience that meets their specific needs. This innovative type of DXP is essentially an assembly of best-of-breed solutions to deliver content and digital experiences to customers in a much more agile, flexible and efficient way than a single monolithic platform.As opposed to the traditional monolithic approach taken with DXPs, this microservices approach enables companies to cost-effectively customize their DXP according to their business needs. Furthermore, allowing for a greater level of scalability and interoperability allows faster time-to-market for new features or services, as well as improved customer satisfaction.The composable approach gives organizations better control over their digital experiences and helps them stay ahead of their competition by enabling them to focus on innovation instead of maintenance. A composable solution makes it easier for businesses to move quickly while keeping up with the ever-changing technology landscape.What to consider when comparing a composable and monolithic DXPsCan the platform integrate with solutions your team currently uses?Monolithic suites are large programs often made up of products obtained through acquisitions and then given a makeover in terms of branding and user experience to fit into the overarching process. Such products lack the open-source code needed to integrate them seamlessly with other solutions, which can limit their utility as part of a more comprehensive DXP solution. This technique makes it simple for internal integration, but external integration can be difficult or even impossible.On the other hand, with a composable DXP, external integration is better facilitated due to its ability to connect with existing best-of-breed solutions more readily. As such, organizations have more control over how their digital experiences are created and tailored for their specific audiences. Furthermore, each individual component can be monitored separately from the rest of the system, allowing for greater visibility into performance and ease of scalability when needed. Ultimately, a composable DXP offers organizations greater flexibility and agility compared to monolithic platforms by providing enhanced external integrations and visibility into performance metrics on an individual basis.How much time will it take to deploy the platform?Deploying a new monolithic suite can require significant time and effort — sometimes months — and demands constant monitoring for unexpected changes or challenges during set-up.Moreover, it's necessary to ensure that all employees acquire the required skills to work effectively in this new environment. Besides the technical implications of such large-scale transition projects, there are also social and psychological implications that business leaders should take into consideration. Companies must be aware that transition periods affect team dynamics and thus must create an atmosphere of collaboration that encourages employee engagement and satisfaction throughout the process.On the other hand, a composable DXP approach allows companies to start quickly, taking advantage of the existing knowledge their staff already has. This strategy eliminates the need for extensive training since they can be up and running with a condensed feature set using workflows they're already familiar with.How will we keep the platform up-to-date?Companies can easily keep their composable DXPs up-to-date as the various vendors focus solely on perfecting their solutions. Additionally, organizations can frequently enhance open-source products with improved customizations and updates that won't depend on the vendor.For monolithic suites, a single vendor provides updates and new features; however, some of these “nice-to-have” additions may take an extended amount of time to be implemented to the platform — if at all. Even minor bugs can be left without resolution until suite-wide updates are rolled out. Companies should be aware that they may not always get timely fixes for any issues they encounter while using DXPs with a single-source provider.How secure are these platforms?A composable architecture allows security updates and patching solutions to be implemented quickly for each component without hindering other systems. This expedited process allows for swift response times in case a breach or vulnerability is discovered. However, if a security flaw is found in one component of an entire suite, it can likely extend to the whole system, thereby rendering the entire suite susceptible to exploitation. Consequently, organizations must take extra care when monitoring their suites for security flaws to ensure that all corners of their system are protected from malicious actors.On the other hand, monolithic solutions can be patched as a single software package. Still, patches may need to happen when the system is not being used, causing extended exposure to vulnerabilities.ConclusionComposable DXPs offer more flexibility and agility compared to monolithic platforms. This means they can scale better, have new features and services faster and improve customer satisfaction. They also provide shorter deployment times, easier updates and enable responsive security updates. However, while they may be more flexible than a single-vendor platform, companies must still carefully monitor their systems for any potential security flaws or vulnerabilities that could put their entire suite at risk. Ultimately, businesses can make informed decisions about which type of system best meets their needs by understanding the differences between these two approaches to digital experience delivery and the pros and cons of each.Learn moreLearn more about composable architecture in our guide, “The ultimate marketer’s guide to composable DXPs.”Schedule a free demo to see how Contentstack’s composable DXP can help your organization deliver the digital experiences your customers crave.
How to switch from a monolithic to a composable architecture in 7 steps
Learn how to switch from a monolithic CMS to a composable content management platform in this step-by-step guide.
You may find interesting
Learn how to drive business forward and build better customer experiences.
For executives
For digital leaders
For developers