This is a transcript. For the video, see An Overview of Decoupled Applications & Systems - Part 1.
[00:00:00] Michael Meyers: Hello, and welcome to another Tag1 TeamTalk. Today, we're doing a deep dive on decoupling applications. I'm Michael Meyers, the managing director of Tag1 Consulting and today I'm joined by Preston So, the editor in chief and author of Decoupled Drupal in Practice. This is part one of a two part series. We're going to be talking about an overview of decoupled applications and systems in general, and our follow-up segment will be decoupled Drupal, specifically. Preston.
[00:00:28] It's exciting for me today. We're turning the tables. Usually you're moderating these conversations. So I'm excited to put you in the hot seat and have a conversation. This is a topic that, you know really well, and I appreciate you taking the time to talk to us about it today. just start I, I think it would be helpful to step back, not everybody's familiar with decoupled applications in general.
[00:00:50] What is a decoupled application?
[00:00:54] Preston So: Sure. Thanks so much for having me and, and yeah, it's a real pleasure to be on the other side of the picture at this point and be the guest on the show. you know, it's an interesting name, the word decoupled applications. And I think one of the things that's really important to think abou is the history of software architecture and the history of how applications have been architected and implemented over the course of time. decoupled today has a very different set of connotations in the context of web development than it does in the context of a web development 20 years ago.
[00:01:24] And I want to just kind of dive into that just very briefly. When we say decouple, let's start with the word decouple. Cause I think that's a very loaded term. There's a lot of stuff involved and thinking about what exactly do we mean by decoupling? When we say decouple, what we mean is we're trying to separate out certain things that are not necessarily meant to be part of the same overarching architecture or overarching monolith into pieces that are more appropriate for those needs or more appropriate for some of the things that certain applications or certain layers within an architecture needs to do.
When we talk about decoupling we really have to think about the way that web applications used to work about 20 to 25 years ago, which is that starting out there was really nothing, nothing like the kind of client side innovation that we have today, nothing like the sort of amazing interactivity and amazing JavaScript libraries and frameworks that we have today. Back in the day. The very first notion of decoupling was really about. actually, how do we separate concerns?
[00:02:29] And that's a very key phrase in the sense of architectural decoupling is separation of concerns, which means certain things that are important for a particular purpose. Let's say rendering data, right. Should not necessarily be part and parcel to, or in the same kind of silo as fetching that data or manipulating that data or transforming that data.
[00:02:52] So in the early days of web development and the early days of server side software, right server side kind of architectures and you know, CMS is like WordPress and Drupal. And you know, even some of the ones that are even older, like movable type or expression engine, actually fit into this kind of model where you would have a certain layer on the server side architecture that would be responsible for handling data.
[00:03:18] That would be like a database. It would be retrieving data from an external source. It could be also transform that data into a format. That's more understandable for people who are trying to work with that data, but all of that, and all of those kinds of data related concerns are supposed to be completely separated and completely distinct from the rendering of that data or the presentation of that data.
[00:03:43] So what's interesting is that when you look at some of these really important monolithic architectures and these monolithic systems like Drupal or WordPress from about from, from the very beginning of these systems existence this has been the approach that they've taken where Drupal has a dedicated layer within its server side that is solely about retreating data and housing data and serving data, but then you have a whole nother layer, which in Drupal is known as the theme layer or the template layer, which is all about handling how that data actually makes it over to the point where somebody can work with that data in terms of seeing it. And in terms of manipulating it and in terms of editing it.
[00:04:22] And in terms of actually seeing that show up on a webpage, for example, WordPress works the exact same way. a lot of other systems work the exact same way and a lot of content management systems today still operate along that kind of architecture. However, one of the things that has happened recently is there's been a bit of a pushback against what we call tightly coupled systems or monolithic systems.
[00:04:43] And that is that with the advent of a lot of these newer development tools and development technologies, like JavaScript and especially with some of these frameworks that are really good at rendering data, maybe not still good at being responsible. Before storing data like React for example, or if Vuejs, or some of these other frameworks that have really gained a lot of popularity.
[00:05:04] One of the things that these developers decided from the very beginning was, Hey, let's figure out a way to separate out these service side architectures that have always been written in PHP or Java or Python, or what have you or Ruby. And let's figure out a way to make it so that we can interact with a lot of this data in a much richer way by presenting it through JavaScript, which is the only language that is executable on a browser and the server, right? Both browser and server. And the really interesting thing is when you take this idea to its logical conclusion, you can see a lot of the ideas that have taken shape over the last decade or so around serving data to mobile applications, serving data, to digital signage, serving data, to conversational interfaces that bear no relation to the kind of where that data came from. the implications of this notion of really caudifying and cementing the separation of concerns in an architectural level where we're [00:06:00] saying that not only should it be individual layers within a single system, They should be two separate systems to begin with, which means that the data layer should be its own system.
[00:06:09] And we should also have a rendering layer that's its own system. And if you think about the fact that especially nowadays, we're no longer talking about just websites as destinations for data, right? a lot of our data now needs to end up in internet of things devices and used to end up in limited reality overlays.
[00:06:26] It has to end up in smart TV interfaces. It has to end up on smart watches. It has to end up on a digital sign in the middle of Times Square. And all of these things are really important. And if we don't have that codified separation of concerns becomes really hard to kind of get to that point. So lately in a lot of the kind of web community, there has been a really wholesale transition over to this notion of, Hey, let's make sure that these architectures are decoupled to begin with.
[00:06:55] And that can mean either benefiting from some of the really interesting new static site deployment approaches that are out there right now in what's called the JAMstack or serverless architectures like frameworks like Gatsby or next JS or knex js. Or VuePress. And then also some of the frameworks and libraries that have really taken root in the JavaScript world, including React, Vuejs, Angular a lot of these frameworks that are really, really great for highly interactive applications and not just for displaying static data. And what's interesting is just to kind of segue into kind of the transitional mode here. When I was at Acquia about whew, gosh, six years ago now I actually worked with the project lead Dries Buytaert. And Kevin O'Leary in coining a new term that we called progressive decoupling or progressively decoupled Drupal.
[00:07:44] And it's basically a transitional state or a compromise between these two worlds. I would say that now it's, it's very much the case that people have pretty much gone over to the fully decoupled model. And that's what we expected back in those days as well. But we also wanted to make sure that the Drupal ecosystem.
[00:08:01] And the Drupal community was equipped with the understanding that they needed in order to make that move over to some of these fully decoupled architectures without sacrificing some of the really great things that make a monolithic system like Drupal really great for some of the websites of the interactive behavior they wanted to enable.
[00:08:20] Michael Meyers: Wow. That's awesome. So from tightly coupled monolithic systems to progressive, to fully decoupled do you think at this point you talked about the internet of things and, and how your data needs to be in, in many different places. w would you say at this point that every application should be decoupled?
[00:08:36] Is, is there still a place for, for tightly coupled or progressively coupled.
[00:08:42] Preston So: That's a good question. You know, I definitely think there's still places for both tightly coupled and progressively decoupled. And the reason I say that is because a lot of people aren't really thinking about some of these other micro sites or micro applications where they want to serve data to.
[00:08:56] Right. maybe there's not a mobile app that they have to build yet. Maybe there's not you know, a VR headset that they have to build for yet. certainly in the next decade or two, I think that the demands on the way that we architect our software architecture is when it comes to web development and databases and all of that, we'll really have to shift to accommodate what I call the channel explosion, which is something you can read about on my blog about how you know, no longer are we really concerned with just websites.
[00:09:21] We're talking about people needing to serve a variety of different applications that are potentially on various. Great different presentation layers that there are absolutely no resemblance to each other. Like if you think about the fact that. A lot of data today needs to be served to things like voice interfaces or chat bots and it also needs to be served to a website and it also needs to be started with mobile app. These are really, really different things. And from the developer perspective, they're really, really different things. However, I think that tightly coupled architectures and progressively decoupled architectures do still have a place.
[00:09:52] And that is when you need to build a website. And your primary concern is a website. You're not so worried about a lot of these other applications potentially, or these other experiences, but you really want to make sure that that website tightly he used to and is faithful to the needs of your data and the needs of your architecture.
At the same time, there's a lot of situations where progressive decoupling is very useful, right? Sometimes you need a website that sort of static data, but that also needs to be able to serve you know, potentially more interactive experiences where you're dynamically updating the page or having some really interesting client site interactions take place.
[00:10:27] But this is not all to say that you can't kind of have a progressively decoupled or tightly coupled website. And still decouple. Right? One of the nice things about Drupal is that it gives you all of the above, right? So Drupal gives you not only the option to have a tightly coupled website.
[00:10:44] You use all the kinds of nuts and bolts of Drupal's theme engine and template engines that drive all of these things. but second you can also use, for example some of these libraries like React and Vue JS within Drupal, and there's actually modules that really do some really interesting things around that architectural paradigm.
[00:11:01] But then there's nothing stopping you from then around Drupal, right outside of that Drupal monolith, actually putting in. You know, some of these other consumers that you might want to have in there, like ARBR interfaces and so on and so forth, just because you are you know, still on a monolithic or a tightly coupled architecture doesn't mean by any means that you can't also serve some of these other applications that don't fit so well into the tightly coupled paradigm.
[00:11:27] Michael Meyers: Interesting. We did a project recently where we did kind of that layered approach. We had a very limited amount of time to build an aggressive prototype. And so we went with monolithic to begin with, but we knew long-term it was going to be decoupled and we knew there had to be mobile applications. And so then the second thing we bolted on was the mobile application, via the APIs, and then the third step was to move to a totally decoupled.
[00:11:51] And it just. It enabled us to rapidly make progress in key areas by leveraging the strengths of Drupal with respect to the front end stuff. And it just it gave us the buy-in and support we needed to get from funding level, the funding level, where we we're, we're concerned that had, we jumped straight to fully decouple.
[00:12:11]You know, we would have gotten to where we wanted maybe a little bit faster but we wouldn't have gotten the funding we needed in these phases. So,
[00:12:17] Preston So: Yeah.
[00:12:18] You know, it's very interesting you say that Michael cause that, cause that's actually a really interesting kind of quandary that- and, and just as a quick, very quick aside here, right?
[00:12:26] That's a very interesting quandary, I think for a lot of consultancies and especially a lot of organizations. in the enterprise that are looking to kind of dip their toes into a decoupling without jumping into the deep end. Right. one of the biggest issues I see, and I think a lot of people have talked about this within the Drupal ecosystem and in the WordPress ecosystem is that this model that we have up until today with the monolithic approach has worked so well that we can almost do these sorts of implementations in our sleep.
[00:12:54] But when it comes to some of these more nifty approaches, right. Mobile applications that might not fit the paradigms that we're used to JavaScript applications that might not fit the paradigms that we're used to. One of the issues I think a lot of customers and a lot of buyers have is why do I want to spend the extra money?
[00:13:12] When the actual results could be identical to what I have today. And they're not thinking necessarily about some of the implications of how this architecture could actually benefit them further down the road by exposing some more of that flexibility and extensibility for some of these channels that aren't necessarily as easy as the web.
[00:13:30] Michael Meyers: Yeah. In the middle of a, of a paradigm shift, literally like complicating things in their case, they had. you know, we had built this distribution for them over time that had been really successful. So it had their corporate theme, accessibility changes. Like there were so many things that they got out of the box to rapidly launch a new site.
[00:13:48] That is what made them love Tagline and Drupal to begin with. So yeah, going through this, this change it just it's an adjustment for, for organizations to get through. So it was cool. So there's no you don't have to start with a decoupled application. You can, you can add it on in layers and I think that's, that's a huge benefit to doing this. You know, you can bolt it on or you can design it from the ground up. You're not locked into any one approach, at least for the some technologies. and, and that's great. What are you know, you talked about React and Vue and, and all, all different sorts of approaches.
[00:14:26] What are some of the more popular technologies right now, if you are looking at building a decoupled system?
[00:14:34] Preston So: Yeah, that's a great question. Yeah. So one of the things that's really exciting, I think about the last five to eight years or so in particular, is that there's been a proliferation of products and services that are really focused on this model of how do we kind of provide platforms that aren't necessarily going to be overkill for a lot of these architectures. and it really depends on the kind of experience that you're trying to build in terms of the digital experience. Right. You know, some of these things could involve content. Right. In which case you really want to have a content management system that isn't necessarily a monolithic potentially like Drupal but could be more nimble in its way of actually serving content.
[00:15:14] But Drupal could also be a good solution. If you have other needs that a Drupal provides. But one of the things that I think is really interesting is that a lot of people are now kind of picking and choosing - it's like kind of being at the candy store and saying, Hey, well let me, let me just go and grab some gummy worms for a bit.
[00:15:29] Try those. Then I'll go over here and grab some candy corn, try that for awhile. Let me go over here and grab some sour patch kids and I'll put no put them back or put them in this separate bag over here. And what's interesting is that there's now these emerging categories of different products and services that allow you to kind of flexibly use them however you want it to. And this is part of the paradigm that I have been working on called the distributed CMS, which I see as the kind of next stage beyond headless CMS and decoupled CMS and, and decoupled systems in general, which is a distributed approach to how all these products and services work together.
[00:16:06] What I mean by that is, let's say that you have a website that is built in something like React in a technology that is totally foreign to some of the server side technologies that we work with. And you want to enable some commerce functionality. You want to enable some content delivery. You want to enable potentially some sort of, of you know, let's say some kind of like, music player as well.
[00:16:30] I'm not sure, but you know, all of these different concerns has a kind of headless or a decoupled platform that you can rely on. Right? So Drupal is one of those, obviously you can rely on for the content delivery. But there's plenty of others, right For example, Contentful is one of the diamond sponsors of the conference I run every year, Decoupled Days, and they provide headless CMS services for developers who are building a variety of different content driven applications for their needs. And there's a bunch of different headless or decoupled CMSs that are out there today. But now there's also emerging headless commerce and headless and decoupled commerce tools.
[00:17:07] So one of the things you can do is, is use something like a commerce tools, for example, which is just the name I'm throwing out there as the first one that popped into my head, which provides a headless approach to commerce delivery. So if you need a place to house your price, fixing information you want to drive your checkout process through a particular way.
[00:17:24] You can use some of these providers in a very flexible way to actually do those things. and then for things like. Search for things like form handling for things like you know, a lot of those sorts of things that are a lot of different tools out there, like for search there's Algolia, which is now very popular.
[00:17:39] As well as for authentication is Auth0 and then for a form building, there's now tight. Foreign and all three of these companies are very popular actually. I believe at least Auth0and possibly Algolia were both just named to the enterprise cloud 100 or some lists of, of kind of really up and coming kind of software providers that work in this headless and decoupled space and really provide that flexible platform for developers.
[00:18:05] Michael Meyers: So, so with a headless front end, you can glue together. multiple specialized systems in the backend, like PCI compliant, commerce capabilities, and yet present a. Single interface to your users, as opposed to having to bounce them off to a third party payment system with 16 different redirects and five different URLs and come back to your site.
[00:18:30] Preston So: So exactly you don't see your, you don't see your URL bar kind of go like a, like a train station you know, like in Grand Central, where now I'm no longer there.
[00:18:42] Michael Meyers: I missed that thing. so and, and also for companies like something that we did. We enabled Fortune 500 - glued together different CMSs because different departments were locked into Adobe licenses or preferred it.
[00:18:54] And they had different versions of Drupal, et cetera. And by moving to a decoupled system, one, they could unify everything and no one was the wiser, you know it looked the same to everybody internal and external. They just happened to be using these systems and two - it, that enabled them to do a more seamless upgrade.
[00:19:12] You know, so they were able to migrate from an older version. And one of it was like Drupal 6, and one of it was Drupal 7 and they over time migrated both of those to 8. And again, no one noticed and they able to do it in a as opposed to these like again, monolithic, redesigns and rebuilds, they were able to very sanely and cost effectively migrate things over time.
[00:19:34] Preston So: You know, and you know, it's really funny you say that because this is actually one of the primary benefits of not only decoupled CMS, but also the notion of distributed CMS that, that I've been working on over the past few years, which is that yeah. Decoupled updates.
[00:19:46] It's just make the update process so much easier, right? No longer do you have to put yourself put up a maintenance notice or you know, an animated GIF of a construction worker like we did in the nineties because Yeah, cause, cause cause invisible to the user, some of these kind of changes in these evolutions that you're implementing within the architecture and it's very interesting that you say that because my personal website actually Preston.so is also exactly that that kind of architecture, it pulls from multiple different CMSs. I have a Drupal 8 site that serves some of the content. I have a Contentful, a CMS that serves of some of the content.
[00:20:24] And I also have an Oracle content and experience back in as well, that's sort of some of my content because I work at Oracle. So you know, this kind of idea of a distributed approach to CMS architectures. Because really taking hold and really becoming very popular and you know, some people have different names for it.
[00:20:41] There's some people like to call it composable. I don't necessarily like the word composable because you know, composable implies that anyone and everyone can, can kind of put these things together, like Legos, but that's really not the case. Right? Like I'm somebody who doesn't write code, can't just plop together some of these Lego pieces and just have at it.
[00:20:59] So I call it more distributed architectures or distributed CMS because it's more of, kind of a correct definition of what people are able to do with the sorts of things, as opposed to composable, which kind of says, Hey, like, You don't have to be a developer to compose these things together, which actually isn't the case.
[00:21:17] Right. It's, it's not true. So but I think you see that a lot in some of these new terms that are coming out composable, digital experience platform, composable commerce you know, composable yeah. and, and composable consumer customer experience. So one thing that's very interesting is that these models and these approaches and these paradigms have now begun to take hold, not only in the architect and the developer community, but also in the enterprise world and in the kind of corporate space, which is becoming a really interesting kind of shift in the discourse around all of these things.
[00:21:52] Michael Meyers: I love how your personal website is more sophisticated than most enterprises.
[00:21:59] Preston So: It is. It is. And it's interesting. Cause I use certain features from each, right? Like there are certain things from each that are, that are really good, right? Like Drupal has this really rich content modeling that makes it. Super easy to you know, create these really rich kind of structures of data.
[00:22:14]I use Contentful who once again, as a diamond sponsor of our Decoupled Days Conference because they are doing some really cool things with rich text handling. So you can take a rich text field that has a Wiziwig editor. So like a CK editor kind of thing. And then what'll happen is that Contentful actually translates that automatically for you into an abstract syntax tree an AST.
[00:22:36] That you can use libraries in React or libraries and Vuejs for, to actually translate that into however you want to format it. which means that let's say you've got, let's say an IOT application or a smart TV application that uses some kind of weird XML format. Right? this rich text kind of tree can translate directly into that kind of, you know, XML format, however you need to, to do it. The one reason I use Oracle Content Experience, which I love is because of its security, which I think is one of the topics that we want to talk about next. And that is that Oracle Content Experience has some amazing channel based delivery system, which means that what the destination is, what content should be available publicly. Right. Drupal doesn't really have that because in Drupal if you have access to the APIs, Or how the data is, is exposed. That data layer, you have access to all of it, right? Everyone has access to all of it, unless you configure something using the consumers module or a really complex rules and permissions, but Oracle content experience makes it super easy.
[00:23:38] To say, Hey, this content goes to this particular set of channels, right? Let's say React and ARBR, but that data should never be exposed to somebody who's building, let's say an AR VR application over here that shouldn't be able to have privileged access to that data. So for that reason, I really liked the security implications that and the security feature sure is that our Oracle CMS provides in a headless way.
[00:24:01] Michael Meyers: So security is a concern then with respect to, you know, the data that's being exposed, coming up with permissions in certain contexts, it, it sounds like it complicates things a little bit. It gives you a lot of flexibility, but you know, with some complication You know, we talked a lot about the benefits and I mean, there's so many amazing things about decoupled.
[00:24:25] You know, what I struggle with on, on the downside a couple of things potential security On one hand it's so great to see innovation in the CMS world. Like it's, it's been stagnant for 15 years. I shouldn't say stagnant. It's just, there there've been no, like major players come into the picture.
[00:24:41] You know, we've had the same giants, WordPress, Drupal, things of that nature. And in the last few years you know, it's been this insane explosion of technologies and on I think that overall that's, that's great. And I, and I want more of it. I hope that continues. On the other hand, I look at organizations and large enterprises.
[00:25:03] And one of the ways that they're successful is through things like standardization and I think it's really, when you're saying, well, I'm going to take all these different Lego blocks. I'm going to build together this application. Well, now you have 10 different technologies that you and like another team comes in and inherits this and they like 10 other different technologies and a hundred new ones have come up.
[00:25:24]You know, all of a sudden you have this massive technology sprawl, that's you have security challenges, maintenance, challenges build challenges like you know, do you see consolidation happening because this is just a necessary evil to foster innovation and get us to where we need to go.
[00:25:42] You know, am I a Pollyanna here? Like, can corporations deal with this? Like,
[00:25:47]Preston So: Yeah, this is a really important issue. And this is something I write about all the time in CMS wire. if you check out some of the columns I've written for CMS wire, this is a topic that comes up over and over and over again.
[00:25:57] Right. And one of the things that I think is very interesting is that it's a series of trade-offs and the trade-offs can be very pitched. And you know, one of the things that I always say is that yeah. you know, one of the nice things about this kind of notion of distribution, right? This notion of decentralizing, your application architecture, is that it gives you a lot more freedom when it comes to developer experience.
[00:26:18] When it comes to flexibility, when it comes to sensibility, and it also gives you a lot of flexibility when it comes to vendor, lock-in. Because if you're just using Auth0 to power, this little authentication layer, or you're using Snipcart to power, this cart checkout system. When those two companies fail, you just have to switch it out for a different authentication provider or a different card provider.
[00:26:41] And there's, there's hundreds of companies out there now that are providing these sorts of things. But. On the other hand, right? The notion of distribution and the notion of decentralization also has really big implications on the ability for us to actually manage these architectures in a low maintenance and highly secure way, because now that you're introducing a whole lot of different providers and a lot of different services, some of which you don't necessarily have control over that introduces more points of failure.
[00:27:09] It also introduces more surface area for security vulnerabilities and security attacks. Right. you know, somebody could take down one of these providers with a DDoS attack and you would be none the wiser unless you were really privy to some of that kind of communication that happens around those things.
[00:27:25] So in some ways I think that we're in a very transitional period where developers definitely see the value of this kind of distributed or decentralized architectural approach to application development, but they don't see the value. the, the people who don't see the value are the back office folks, right?
[00:27:45] The editors, the compliance officers, the lawyers, the project managers, the product managers, the designers, right, who don't write code, but they need to be able to be very deeply involved in the collaborative process, around serving data and serving content to applications. And this is where I think there's been a bit of a kind of a bit of a severing of some of those really important needs for these folks.
[00:28:11] And so. You know, in terms of the future, I think what's gonna happen is we'll need to see better integration stories, better stories that democratize the experience for those who don't write code. Because right now, when you say composable, right? When some of these folks like Amplience and Netlify talk about composability.
[00:28:30] You're talking about composability for the architects and for the developer, not for the editor, not for the compliance officer, not for the not for the CMO who needs to be able to see how this is going to look in 15 different applications. so it's a very exciting era because I think we'll begin to see some really innovative solutions around these sorts of things.
[00:28:49] I'm working on some very exciting approaches to this kind of problem space at Oracle. And you know, time will tell, as I said, in my latest piece for CMS wire or sorry, my interview with CMS wire by Dominic Castro about the latest Gartner DXP magic quadrant. Time will tell who's going to ride the right mix of solutions to and, and the right integrations and the right kind of surface area to get to the point where
[00:29:15]Architectural approach being available, not just to the developers and the architects and the audience, but also those who couldn't care less about you know, the fact that we're using JavaScript or the fact that we're using XML payloads instead of JSON and, and really just care about the fact that they want to preview and see their applications in context.
[00:29:33] Michael Meyers: Interesting.
[00:29:34]what about the developer experience? It does that get we talked about sort of like the corporate pros and cons I would imagine there's many things that developers love about this, but what about like the build process and yeah. You know, does, does this complicated streamline it?
[00:29:52] Both?
[00:29:54] Preston So: Yeah. Both. You know, I think, I think so, so there's definitely you know as we know, right. There's, there's things that will. Like when you, when you help a certain group of people, you're also potentially hurting other group of people. Right. So whereas I see that a lot of developer experiences when it comes to things like client side development, server side development rendering, right?
[00:30:13] A lot of these approaches that happen closer to the user experience and closer to the edge. These sorts of things are much easier. For developers, right? These sorts of things have become, almost incred... Like the amount of change that I have said. You know, I started writing websites and I started writing HTML and JavaScript in 2001.
[00:30:32] So 20 years I've been in this business and I've been programming since 99, but in the 20 years that I've been in this business, it has struck me just how much the kind of development approach for the front end and back end systems that we routinely deal with have changed over the past just five years.
[00:30:50]it is completely unrecognizable. Like if you, if, if I were to travel back in time and show my my you know, nine year old self some of [00:31:00] these things, right? Like here's, here's Chrome dev tools right here, Chrome's lighthouse tool, right. Here's Babble, which is transpilation from ES. You know, six to regular JavaScript here's Webpack, which does arbitrary bundling and amazing things for JavaScript.
[00:31:15] I would have laughed in my own face because these things are so foreign so the way that we were building websites back in 2001, which is HTML, CGI scripts, Perl, right. and, and no JavaScript to speak of, except for maybe some rudimentary alert messages and things like that. Rosso and rollover image, image maps.
[00:31:39] Right. so, so but on the other hand, right at the same time, I would say that when it comes to the infrastructure, when it comes to some of the newer concepts of continuous integration and continuous deployment and some of these notions of dev ops, right? I've been a dev ops architect since, Oh gosh, about seven years now.
[00:31:58]I don't really do that much anymore because I absolutely despise infrastructure and I despise CICB as a, as a specialty. But a lot of those things have actually become a lot harder, right. Because no longer are we just putting files up into an FTP server and calling it a day right today, we're talking about pipelines and we're talking about.
[00:32:16] integrations. And we're talking about services that deploy and build and bundle things and actually execute certain scripts that are not even part of the regular code that we're writing. So when it comes to the kind of application development side of things, I think that the world has become much better.
[00:32:34] And I think the world has become in some ways, a really easy and simple. But for the people across the across the floor, right. And who are sitting in the other cubicles, who are, who are constantly monitoring performance, who are looking at uptime, who are trying to manage all these deployments and load balancers and all these things.
[00:32:52] In some ways, I think it's actually become a lot harder. Because these paradigms are not the same as they used to be. There's now big gulfs and big differences between different deployment between different deployment approaches and different CIC approaches. And one thing that worries me is that we're seeing so much innovation when it comes to the front end.
[00:33:12] And we're seeing a lot of innovation when it comes to the dev ops and CIC with things like Kubernetes and Ansible. but in some ways I think that a lot of the things that are happening around Docker and Kubernetes and Ansible and, and container and cluster driven container and cluster driven infrastructures.
[00:33:29] Are actually making the story even more complicated potentially. so it's one of those things that is kind of a trade-off, I'm sure a dev ops architect who works with Kubernetes and Ansible every day would probably actually disagree and say, it's the opposite and say that it's the front end, that's gotten more complicated.
[00:33:44]and, and that's just a kind of a perspective thing. So
[00:33:47] Michael Meyers: I think one of the beauties of technologies are layers of abstraction. So. You know, the fact that you can build on the front end, even the back end and not have to deal with theinfrastructure is great, you know? and hopefully these things will get easier over time point and click deployment.
You know, I don't ever, ever have to talk to dev ops engineers. We can just leverage the services that they provide us.
[00:34:11] So
[00:34:11] Preston So: Yep. And even better would be, Hey, what if there's a way for somebody who is a content editor. who, who needs to have this, you know content go live immediately because there's some kind of a power outage or something, and they need to have some kind of advisory go out.
[00:34:25] Why can't they drive that too?
[00:34:27] Michael Meyers: Yeah. Yeah. I, I that's that's happening. It's we're working on a really cool system right now. That's essentially that allows anybody in the organization to deploy a microsite or a full website like a massive application stack. With the corporate look and feel with the push of a button sort of like tying together, all these things we put in place.
[00:34:46] And it leverages Kubernetes and EKS at least and Pulumi and all these things. And so hope they're, they're coming together. but there's a tremendous amount of complexity here and a lot of people involved and you know, but, but. You know, looking back to what we did 20 years ago you had to set up your own physical servers in a data center and So, yeah, it's, it's amazing to see how far things have come.
[00:35:11] It's a little daunting to see the how quickly things change, but it's exciting as well. As always Preston, this was amazing, dude, this was so much fun. I hope that folks stick around for part two. We're going to dive specifically into some things with decoupled Drupal Preston mentioned a lot of things we'll link to them in the show notes.
[00:35:31] please remember to upvote, subscribe, share this out if you liked it. And I hope you did. you can check out our past tagteamtalks@tag1.com/tagteamtalks. We would love your input and feedback on this episode, as well as suggestions on future topics that we can cover. You can email us at tagteamtalks@tag1.com and again, a huge thank you.
Really appreciate you joining us today, Preston, and look forward to seeing you again in the future. Take care.
[00:35:58] Preston So: [00:35:58] Always a pleasure, sure. Thank you.