Composability: The New Architect in Town

Harshil Agrawal 0:00
I’m super excited for this talk today, my talk is titled composability, the new architecture in town. Now, some of you might have heard about composable, architecture or composability. And for some of you, this might be a new term, well, don’t worry about it, I’m going to help you understand what it really means. Before I jump into it, I would like to thank Brian and the whole CFE team to organize for organizing this conference and giving me the opportunity to come and talk and share my knowledge with you all. And also a huge shout out to the AV team, I had a call with them earlier as well. And they have been amazing. And this is, this gives us more confident is the speaker to come on the stage and share our knowledge with you. So thank you, Brian, and then the holy. Alright. Jumping into the talk, I want to do a quick introduction about myself. As you all know, my name is Herschel everyone. And I work as a developer advocate at Contentful. For the folks who don’t know what content fillers and I am going to do a small introduction. So Contentful is a composable content platform with an API first architecture, which means that using Contentful, you can manage your content, as well as orchestrate content from other platforms, and distribute that content or publish that content on any digital channel of your choice. But that’s what that’s about Contentful a bit more about me, I like to think about myself as an experimentalist. Because I try out different technologies. Some things you might have heard some things you might have not heard, and like to share that with the community. Recently, I have been working and playing around with the web HIV API. If you don’t know that API, it’s basically an API that allows you to connect any of your HIV devices to your web applications. If you want to learn more about it, you can go on my website and check out a couple of talks that I have given around web ID. And I am also learning digital illustrations, this has been happening for six months. Now. I don’t know if I have made any progress in that. But I’ve been enjoying the whole process. And it’s fun. And everything that you see on this particular slide is basically all the art that I created myself. Alright, enough about me, let’s jump into the talk. So the agenda for this talk looks something like this, we’re going to build a website together, which is going to be a lot of fun, we’re going to learn a lot of new things, we’re going to talk about things like monolithic architecture, and the limitations it has. We’re gonna look into micro services, and talk about how it overcomes the limitations that monolithic provides. And then we got to later on jump into composable architecture, which is the main theme of this talk. Alright, so let’s move forward, we know that we all want to build a website. So the first thing we do is we do a bit of research, we do a look at the requirements that we want our website to have.

Harshil Agrawal 3:13
So I did a bit of research. And I look into the things that I want to have in my website. The first thing I wanted for my users to do is like, have the ability to go and shop things that are available on the website. So shopping was one of the features that I wanted to have on my website. But I didn’t want it to stop that. I wanted my users to also go and learn new skills on the website while they are shopping. Because why not right? So learning became another product, part of my website. The next step is, well, the users are going to shop, they’re going to learn new things. I also want them to have some kind of entertainment in there. So I decided, hey, why not plug in a system where people can just go watch some stuff, maybe look at some cat GIFs and have some fun. And while I was low listing out all these features, I thought, hey, it would be great to bring people together and have socialising expect to this whole website. Now let’s take a pause over here. And think about our usage of internet every day. We are using the internet for either of these four things, right? We are either looking for something to buy a researching on something that we want to buy. We are always learning new things. We are using social media platforms to connect with our friends with the community with our family. And we all use it for some kind of entertainment as well. If you think about it, all this is also connected with one thing and that is content. Everything that we see on the internet is basically build of content and over the past couple of years, the amount of content that has been generated is massive. It’s not just a generation of the content that has increased, but even the consumption of content has increased. Now, I want to build a website, I want to build my own business. So I need to make sure that I know what my competition looks like. And this is what it looks like. There are roughly 2 billion websites online. As someone who wants to start their own business, this is my reaction like, what? How am I going to be able to grab the attention of my audience, make them stay on my website, make them use my website. But I am someone who is very ambitious and would like to take up challenges. So I said, Hey, you know what, let there be 2 billion websites out there, I’m going to build the best website that my users which are dogs are going to enjoy using. So it took the time took up this challenge. And I started working on this.

Harshil Agrawal 6:03
But there was one thing that I thought, when I first started to write the code was like, what happens if all the adults on this planet? Use the website at the same time? Will my website scale? Will my website be reliable for all my users to access it? And this is where I started to have more conversations with my team started to discuss potential solutions. And one thing we also learned during this journey was content is the king content will help us get more traction. So we started focusing on the marketing part, while we were still building our product. So with the first step we took was, hey, you know, let’s just have a static web website, where all the content is also static. So it becomes easy for everyone to get started. But that was a terrible approach, because it introduced a lot of problems. Because it was now a static website with. But let me rephrase this, because now the content was static, it was difficult to update this content, everything set within the code itself. So if my marketing team wanted to update a content or added new content, they could not directly do that, because they were semi technical or not, or did not have the knowledge of the code base. This, we also look into the problem of no history for the content that we have. Now, again, we do have history for the code, but not exactly for the content, which again, was an issue for our marketing team, because we might launch a marketing campaign, but on the wrong time, and we wanted to like roll that back. And this was not really possible with this study content approach that we took.

Harshil Agrawal 7:58
And lastly, it was really time consuming, because every time we wanted to have new content out there, we would have to bug the engineering team, open up a JIRA ticket for them, they would add it in their cycle, and then publish that whenever they had time. And while they were doing that, we were also losing time on building out the core features. So static content didn’t really work well for us. So we started looking for another solution. And we came up across CMS, CMS is basically stands for Content Management System. And they basically allow your teams to work in silos. So your marketing team would now be able to work on the content that they want without heavily depending on the engineering team, which was really good. But the legacy CMS systems introduce new challenges for us. They do slight side rendering. Now dogs, if I have to tell you this, they don’t like to wait for websites to load, they want everything just instantly on the on the browser. So client side rendering wasn’t a friend over here. This gave slow results to our users, and was no fun. And it also gave introduction to monolithic architecture. Now I’m going to not talk about monolithic architecture on this particular slide. I’m going to cover that later on. But just keep in mind when using a legacy CMS system, you don’t really get a lot of flexibility. Alright. Moving forward, we thought alright, CMS was a good approach was a good idea. But it didn’t really solve a problem. It introduced a couple of new problems. That’s where the headless CMS helped us out. Now headless CMS takes an API first approach, which means that your content layer is separate from your delivery layer. All the content that your marketing team or nhsa is on a platform, which can be connected to your front end via an API. Which means that now you can use one single platform and publish this content to any channel that you want. We were looking into this new tech, things that the dogs were really into, which is like AR VR. And dogs also like to use mobile applications a lot. So we’re like, okay, headless CMS can be a good approach for us, because we can now have one platform where we can distribute this content, or using this platform, we can distribute content on the ARV apps that we have on our mobile applications, and on the website, as well. And engineers love this as well, because it was front end framework agnostic, so they could use the latest JavaScript framework that was released yesterday, and they could quickly build up the website from scratch. So this was fun for them as well. But while we were building this, while we were creating our product, while you’re creating a website, we learned a few things, we learned that we are not just using one platform, we are not just using a CMS. For our digital assets, we were using digital asset management system. So this would handle our audio files, or videos or images or PDF files. Think of any digital asset that you might have. We also have a shopping feature on our website. So we wanted to use something that is called a product information management system, which allows us to basically manage the products that we have. Being ambitious that we here we thought hey, why not also use an ECM, it will give us a full fledge flexibility a full, full fledge set of features to make it a proper ecommerce website. So we thought like, hey, let’s use an ECM as well. So we’re using all these three platforms on top of a content management system. But if you think about it, it really is not an ideal scenario, because now your teams are working in silos. The team that is managing your current information is not communicating a lot with the team that is managing your blog content or the marketing content, right. So you often might have a miscommunication or no communication at all, which would lead to inconsistent user experience. Now that dogs would see some information on the product page, while a completely different information on the marketing website, which was really not a good experience for them.

Harshil Agrawal 12:43
And lastly, this also introduced slow development speed for our engineers, because we had to have four different platforms to integrate to our website, we had four different API’s to work with four different API structures to look at. So really not an ideal scenario for us. So we all got together, sat down in a room and started thinking about potential solutions to overcome this. We, we had to use all these different platforms to to have a stream to have a proper streamline workflow. But it also came up with all these limitations. So we are not exactly so what should we do? And how do we approach this, this is when we learn about monolithic architecture. Now, I’m going to explain you what monolithic architecture is with an analogy. So this image represents a jigsaw puzzle. And for the folks who don’t know what a jigsaw puzzle is, it’s basic, it’s basically a set of pieces, as you can see on the slides over here, which are arranged in a way that would complete an image and make that person look complete and look more pretty. But there is a catch regex or puzzles, if the, if one single piece is missing, it looks incomplete, it looks broken, and you cannot swap pieces with each other. Or you cannot introduce new pieces over here. Because then it breaks your whole puzzle, it breaks your whole image. And that is not a good thing. So these were also like the limitations that the monolithic architecture came with. The first thing was like It introduced slow development speed, because with each of these species, they were needed to set they were needed to be placed in a particular order. And if one piece wasn’t there, the team would have to wait for that piece to complete that component to be developed and then start working on the other part of that particular website to this introduces slow development speed. Then there was the issue of scalability as well. These pieces were so dependent on each other, that they would scale up all together. They will scale down all together, these pieces would not scale up or down individually. This also kind of had resulted into the problem of reliability. Because if one piece was missing, basically a puzzle was incomplete, a puzzle was broken. So if one component of a website was down, a whole website would be down. And introducing new components or new pieces in here would not, was not feasible, it would take a lot of work, and wasn’t really a good choice for us. So we looked for another solution. And we knew like, these were the initial limitations that we’re gonna get into. So we were like, alright, this is not going to work, we need to come up with a better solution, that’s gonna help us overcome tension. And that’s where we look into microservices.

Harshil Agrawal 15:58
Now we’ll look into monolithic architecture as a jigsaw puzzle. The way I like to think about microservices is like building blocks. You can arrange these blocks however you want, whatever shape you want, and whatever arrangement you want to have, they still gonna look good, they’re still going to work, and they’re not going to break. And this is what basically, microservices is, it i these, they are basically building blocks that are independent of each other. And they overcome all the limitations that micros the monolithic architecture provides, for example, slow developments feed. Now that we have building blocks, which are independent of each other, our teams could work indeed, on each individual building blocks. And they did not have to rely on one building block to complete to start working on another building blocks. It was scalable enough, again, because these building blocks are independent of each other, they can scale up and down individually, they were reliable again, because if one thing went down to the building blocks are still gonna work and they’re still gonna be there. And they were flexible, because I can add more blocks to it, or I can swipe out blocks, and things are still gonna work. But this was still not ideal. Because let’s go back to our previous example of the product information page, and the marketing page for us. For us for the same product. We had some information of the product on a product information page. But that information wasn’t consistent with our marketing page, which means that we had content on two different platforms for the same thing, which was not consistent, which was different. And this is where we started to understand the limitations of microservices. Even though microservices came up, and solve all the issues or almost all the issues that we had with monolithic architecture, it introduced a couple of new interesting issues for us. And that’s where this we’re like, alright, okay. Let’s take a quick pause over here, let’s try to understand what we really need. And that’s where we heard about composability.

Harshil Agrawal 18:13
Now, in composability, we like to think about these building blocks as components. And these components have certain characteristics. The first is that these components are modular, which means that you can break these components down into smaller components, and reuse these components across your website or across your application. And the other thing is that these components are interoperable, which means that these components can talk to each other, whenever needed, which overcome the problem that we had earlier. So if we had information on one platform that we wanted to reuse on another platform, with the composable architecture, we could do that as well. So now that we have a CMS, we have a DM, we have a PM. And we have an ECM, remember, we still have this four systems. We know we want to take a composable approach. But we’re not exactly sure how to do that. Because composable architecture does solve the problem of reusability. But developers still need to work with four different API’s with four different API structures together. Not ideal. And we also needed to make sure that we have reusability in place. But how do we do that? That’s where Contentful comes into picture. Contentful as I mentioned earlier, is a composable content platform, which means that now you can have the flexibility of a composable architecture in your head less content management system. So if you have your information distributed to other platforms, you can bring it to Contentful. Stitch it to whatever you want. And then making just one API call, publish it to publish it to any digital channel of your choice. So now if I have my product information in a PLM system, I can fetch that information into Contentful. Use it in wherever I want, and then publish that out to my digital channels. So here is what composability brings to the picture. It brings this this feature called orchestration, which again means bringing content or bringing information from other platform to a single platform. Because now we have this flexibility. It allows us to reuse this content or reuse this information wherever we want. Now, if you are a front end developer like me, you would be able to relate how components work in front end frameworks that we have, right? We have we create these components to reuse them across our application. And that’s what we do with this composable architecture, we create components that we can reuse across our applications that are closer architecture over here.

Harshil Agrawal 21:06
This is a small video of how you can achieve composability in Contentful. So over here, I have created a shopping website using Shopify and Contentful. I added integration over here. As you can see, I’ve already configured my Shopify app. I love Pokemons. So I’ve added a pokey one over here, and I hit on publish. Now this is available out there. So if I go open up the graph, QL playground and make a query, I can get the information that is already in Contentful. So let’s just first get the title that we already have in Contentful. If we hit this, we get the title, things look good, I can get the product as well. But over here, it just gives me the product ID What if I want more information. That’s where orchestration comes into the picture. And now I can query the product data that I have in the Shopify platform. So the title and description. And now over here, I have the title and a description, which means that now, my content creators, my marketers, they don’t have to have the same information everywhere, they can have this information at one single place. And we can reuse this information anywhere needed in a website. So this is what basically, the layer of the application layer looks like for our website now. So we have a data layer, where we have a product catalog, a CRM and all the data that we need. Then there is a platform layer, which contains all the platforms that we are using for our application, for example, church, personalization, content, etc. And because in our experience, we learn that content is where we want to orchestrate all this information. It is where we want to reuse this information that we already have on the data layer, as well as on the platform layer, we selected content as our orchestration platform. And we now bring all this content to content full and make any and use the API that Contentful provides. And the SDK is that content full provides to publish all this content on the channels that we have. So let’s take a look at the advantages of composable architecture. Because composable architecture is an extension of microservices. It is scalable, each component is modular enough. So they still can talk to each other, but they are still independent of each other. So if when if you want a scale of one component, it can easily scale without without hindering any of the other components. It’s flexible as well, if you want to introduce a new platform to your application, or if you want to swap out your platform, maybe you want to swap out your PIM because you found out there is a new fancy looking PIM which is less expensive and gives you more features, you can do that as well. Because again, early now need to do is connect that pi m system to Contentful. And you have that same structure in Contentful, you don’t really have to make a lot of changes in your front end as well. The next is now we have the capability of reusing the information that we have spread across different platforms. This can be again, digital assets, your product information or any other information that you have. Because we are now reusing the content that we have on one platform we are providing our users with consistent experience throughout our application. So now our users can see the same information that we have on our product page as the same on the on the blogging or the marketing page that we have for this product. And our developers appears well, because components, they can work individually, they can bring the components together to talk to each other. But they are not really dependent on any other component, which makes our developers happy as well. So let’s do a quick recap and see what we covered in this talk. So we looked at that monolithic architecture is like a jigsaw puzzle. And it makes it difficult to introduce new platforms, new services, or new tech stack. Whereas micro services is more like a building blocks. And it is easy to introduce new platforms with microservices architecture. And composable architecture is an extension to micro services, which brings features like reusability, and orchestration to your architecture.

Harshil Agrawal 25:53
Now that we are using composable architecture, our end users again with our dogs are super happy with this and they love coming to the website, shop for their favorite things. Go and have entertainments for them. The entertainment is watching cat GIFs. And you’ll learn new things and just have fun. Right? Thank you all. And I hope you learn something new today. And I’m looking forward to your questions.

Brian Rinaldi 26:22
Thanks, Harshil. Oh, that was great. You know, it’s funny, I was watching that. And I’m like, Okay. I mean, I’ve been a big user of Netlify for a number of times, and they’ve moved also to like this terminology of composable architectures. And so, and they’ve largely dropped the jam stack. And so I, in my mind, I’d kind of thought, Okay, it’s one in the same. It’s just a new, more enterprising version of talking about jam stack. But like listening to your presentation, I’m like, okay, maybe I had that wrong, because jam SEC tended to be more about how you built the site, about the front end? Yeah. Like it was the tooling around the front end of the site, and how you built it, how you deployed it, etc. And it seems like composable architectures is more about the back end, how you bridge all of the different API’s are connecting together into a single consolidated API. Is that right? Yep. Yep. Okay, that’s, that’s interesting. That changes the way I frame it, for sure. Okay, so. So we did have one question from the audience. But again, folks, I’d love to hear your questions. And the question was from David, he asks, specifically about the digital asset management, can the dam be customized based on articles? And overall, can it be organized by categories? I don’t know how much you know, about using them, but I don’t know. I give them swimming. He’s asking Kenneth basically, can you organize it? Like, can so the content the images in the or video in the dam are connected to like the articles in the CMS so like, that, you know, which, which article which which images go which with articles, I think is what he’s asking. Okay.

Harshil Agrawal 28:18
I think that would really depend on how your team structures things, right? Because it really varies from organization to organization and from team to team. And also depends on what kind of DM you are using. Because there might be a DM that will have like an inbuilt feature where maybe you can add tags in there, right? To identify what kind of things or what kind of prevent you should use use that particular asset. So maybe your DM already gives you that flexibility. If not, you might have to have folder folder structure in that DM, I’ve used two or three DMS, and most of them have a folder structure. So maybe that will be an approach that you would want to take, again, like, but the context that I have, this is what I can think of right now. Okay. Okay,

Brian Rinaldi 29:07
that makes sense. So Richard asks, What the preview capabilities of content for arc Do you have live preview?

Harshil Agrawal 29:15
We do have live preview, we released Live Preview. A while back, I think six months back. I’m not sure don’t quote me on that. But we do have live preview. And we are releasing new features for the live preview as well. Some of them are like already available for EAP. But you can go on, add the SDK in your website. And you can just get started with Live Preview on Contentful. We have documentation. We have video tutorials, we have blog posts around that as well.

Brian Rinaldi 29:42
Excellent. And I’m curious. So So you talked about you can integrate all these different endpoints. So is it kind of open ended? I can integrate what ever endpoints I might want or is it? Is it something like I have to have a particular Contentful integration with

Harshil Agrawal 29:59
it So right now, the wonderful team that is working on the orchestration, they are working on making the SDK more flexible. So while they were building this, they were also building or improving the SDK that we have for something called App Framework, where folks can like easily create this or bring this orchestration feature to whatever services they use. So if you are using a service that we don’t really have an app for, you can create your own app, which can give you this orchestration flexibility as well.

Brian Rinaldi 30:35
Okay, so that’s coming, though, you said, That’s not.

Harshil Agrawal 30:38
That’s coming, that’s coming,

Brian Rinaldi 30:39
it’s coming. So in theory, then at that point, I’d be able to say, like, because, you know, I worked for a company that did some of this stuff a few years back, and, and you know, that the idea was, well, you might have like an internal API, like that’s a REST API that’s that you want to connect also like to, you know, whereas you have your CMS, and you have your da M, and you might have your, you know, e commerce, you know, provider, and then internal API. So like, yeah, there’s a lot of different pieces there. Okay. Excellent. So what’s the difference between this is from Ben, what’s the difference between using Contentful? And the data unification layer like Netlify? Connect?

Harshil Agrawal 31:24
I haven’t used net LIFFE, I connect. So I cannot say a lot about that. So he Yeah, I don’t I don’t want to give you a wrong answer. So I just don’t have enough knowledge to answer this question.

Brian Rinaldi 31:36
Yeah, I haven’t used it either. But I think so. I’m assuming that the assumption is that Contentful is the CMS provider in this case, I don’t think Netlify has a built in CMS, you daft actually, one of the connections would be a CMS. So I know, that’s a difference. Beyond that, I don’t know, myself either. You know, so one of the things I was I was also thinking about is, especially because that company I worked for a few years back was all Graph QL. You know, one of the struggles I had was like, like teams hadn’t adopted Graph QL. But it seems like the the entire concept of composable architectures is built upon Graph QL. Am I right? I mean, that seems like, you can’t really do this without Graph QL, I’m assuming you have to like you have to connect to Contentful as Graph QL API, rather than the REST API in order to take advantage of this.

Harshil Agrawal 32:34
Yet, for now, it’s only supported in Contentful. If I talk about, it’s only supported in the graph, QL API, but the team is working on bringing this flexibility to the REST API. But if you think about the about graph, QL API, it’s basically graphs and that’s what we are doing, we are connecting different graphs together to bring this flexibility. So Graph QL made most sense to you know, like, release first. And based on what we the feedback that we get from the users, we’re gonna have, hopefully bring this to the SDK as well, so that people can just, you know, use the Native SDKS that we have, and have orchestration is there as well.

Brian Rinaldi 33:12
Okay, so, so for the moment, it’s not in the SDK is you just you query a graph directly to get off to Libya right now? Okay, okay. Yeah, I mean, I do think, like, this is exactly what Graph QL does best. It’s like, you know, there are there times where it can be difficult to use. But I think, you know, specifically, when you have an in an API that is not necessarily static, like I, in this case, like, I don’t necessarily know, like, the structure of everything I’m connecting to outright to like, be able to say, here’s the REST endpoint that gives you all of these things, right. So, like, it’s perfectly suited for this. So one, one last question here. Katerina asks, What would you say are the disadvantages of composable? Architecture?

Harshil Agrawal 34:04
That’s a good question. For me, I don’t really, for me, I don’t really think that is a disadvantage. I feel like if the like, the way I like to think is, if you are growing, if you if you are a small team, thinking about composable architecture early on, might not be that useful, because then you will have to deal with a lot of different things. And as your company grows, you might have to keep on changing the platforms that you are using based on your use cases. So that’s the one thing that I think, again, like changing the platform is not really a big problem. But you might have to, like, move content across and that’s not really good experience for anyone in in any team. So that’s the only thing that I kind of talked to people when I talk about the composable approach. While we talk about composable everything we want more people to adapt it. I would say like look at this kill of the organization and see if it really makes sense for your organization at this point to adapt that. So that’s the only thing that I can think about as a disadvantage of composable architecture is that people just want to jump in without really thinking about if it’s exactly what they really need at this point of time.

Brian Rinaldi 35:21
Right, that makes sense. I think, you know, and this is not a dig at any particular provider, but it’s just something to think about, I think, is that you also, I would, from my perspective, do you have a little bit of lock in from a provider standpoint, because like, you’re gonna have to re architect. So you have to put some thought into, like, you know, what, what best suits your application upfront, because you kind of, it’s gonna be harder to move off of whatever platform you chose, right?