As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Amazon Prime Video has ditched its use of microservices-cum-serverless, reverting to a traditional, monolithic architecture. It vastly improved the workload’s cost and scalability. (more…)
In a perfect world, every application would run like Netflix–by which I mean every application would be cloud-native, microservices-based, containerized and, in all other senses of the word, modern. Unfortunately, not every application can be transformed in these ways. Some of the most important enterprise applications–like those powered by SAP or Oracle–don’t lend themselves to architectural transformations simply because the vendors don’t support that strategy. As much as organizations might wish that they could re-architect legacy apps from the ground up, the reality is that they just can’t.
Fortunately, though, all hope is not lost if you have an enterprise app that you can’t containerize or “microservices-ize.” Even if you can’t “break down your monolith”–to quote the standard advice you’ll find if you read articles about how to modernize legacy apps–there are a variety of practical steps you can take to make legacy, monolithic applications look and feel (in most respects) like modern, cloud-native apps.
Here are four ways to make your enterprise monolithic apps more cloud-friendly, even if they’re not technically cloud-native.
Most enterprise apps are compatible with the cloud in the sense that you can host them on cloud-based virtual machine (VM) instances using services like Amazon EC2.
By taking advantage of cloud hosting for enterprise apps, organizations can also leverage cloud automation tools, such as autoscaling policies and rules that automatically start or stop VMs. In this way, it becomes possible to deploy enterprise apps in a highly scalable, automated way. You get something that resembles Kubernetes-based orchestration, except your apps don’t actually run in containers on top of Kubernetes. They’re just monoliths that benefit from cloud automation tools.
Load balancers, which automatically manage network traffic flowing to and from applications, are another critical tool that organizations can easily leverage when they migrate legacy applications to the cloud.
Although configuring load balancers for enterprise apps hosted in the cloud is not a strict requirement, doing so can substantially improve application performance and reliability because load balancers help to ensure that requests are directed at application instances best able to handle them. They prevent situations where one instance of your application is overwhelmed with traffic while another sits idle.
Again, this is something that platforms like Kubernetes also do for microservices apps. But, as I’ve explained, you don’t actually need your app to run as microservices to take advantage of load balancing. You can do it with monolithic legacy apps, too.
When your app lives in the cloud and is managed by cloud automation tools, it becomes possible to manage most aspects of application operations via code. Specifically, you can:
● Use infrastructure-as-code (IaC) tools to automate infrastructure provisioning and setup.
● Automate application configuration management using code rather than applying configuration changes manually.
● Codify operational processes, such as application updates and backups, instead of relying on manual operations.
Practices like these, which enable a strategy known as everything-as-code, significantly reduce the amount of time and manual effort that engineers spend managing applications. They also provide consistency and minimize the risk of errors due to human oversight. And there’s no reason why you can’t leverage these practices for legacy apps as well as modern ones.
If your enterprise app is hosted on-premises, you probably manage it using tools and processes designed solely for it. But when you move an enterprise app to the cloud, it becomes possible to manage the application using the same integrated toolchain you deploy for other applications and processes.
You can, for example, take advantage of cloud-based monitoring tools to continuously collect data about application performance and generate automated alerts when something is wrong. Likewise, you can regularly create image-based backups of your application.
This toolchain-based operational strategy is another way to streamline enterprise application management, even in situations where you can’t rewrite or containerize the application itself.
Just because you have a legacy enterprise app that you can’t transform into microservices doesn’t mean you have to settle for legacy management and operational practices. Modern automation tools combined with modern operational strategies like everything-as-code make it possible to achieve an enterprise application management experience that closely parallels that of fully modern, cloud-native apps, regardless of which architecture your app actually uses.
Daniel “Spoons” Spoonhower made a bit of a name for himself while he was at Google, as did his two co-founders of their latest company, LightStep. All three were there at the birth of the microservices wave that has swept through the software world.
They left Google and started LightStep to help all developers build better, more scalable applications.
With its new release, LightStep has pushed the bar higher. In this DevOps Chats podcast, Spoons tells us what they are doing and where he sees things moving.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud and Container Journal. You’re listening to another DevOps Chats. I’ve got a great guest to talk with today, I hope you’re going to enjoy it. I’d like to introduce you to Daniel Spoonhower, better known as Spoons. Spoons, welcome to DevOps Chats.
Daniel Spoonhower: Hi, great to be here.
Shimel: So, Spoons, you are CTO and Co-founder of LightStep, and though some in our audience are probably familiar with LightStep, being that this is the first time we’ve had someone from LightStep on our podcast, I’m gonna ask you to kinda do some of the heavy lifting here and kinda—
Spoonhower: Sure.
Shimel: – tell our audience a little bit about LightStep and what you guys do.
Spoonhower: Sure—sure, sure. So, LightStep provides simple observability for deep systems. We think observability is more than just metrics, logs, and traces, it’s really about being able to navigate from effect to cause. So, whether you’re pushing into deployment, you’re on call and you got paged or you’re just trying to improve performance, observability tools like LightStep should be able to give you the insights that you need to understand what’s happening in your services and across your system.
Shimel: Excellent. And just by way of, again, giving the audience the background—Spoons, why don’t you tell them a little bit about your own personal journey? You are a Co-founder and CTO, but there was life before LightStep.
Spoonhower: True, yeah. So, yeah, I’m Co-founder and CTO and LightStep, but we have three—all three of the Co-founders are technical, and so, we all have done technical things and we all have done a lot of non-technical things, too, which has been pretty fun for me just to learn about finance and about commercial real estate—who knows what.
Shimel: Yeah.
Spoonhower: But yeah, I’m an engineer by training. Before this, I was at Google for a while. I worked both on their internal infrastructure team, which was super interesting, as well as on the cloud platform. And I have various other experiences at big and small companies. I was at grad school for a while doing academic stuff, so—yeah, a lot of different things.
Shimel: Excellent. Alright. So, before we—I know you guys have some new product announcements coming up, but you know, LightStep is, as I mentioned, new to our audience here on the podcast, but it’s been around five years, right? And I think you gave everyone kind of the—you know, the brief elevator pitch about it. But it really, you know, in an age where even just since I’m doing devopsy.kinsta.cloud, right, Spoon, we’ve seen APM turn into AIOps and companies go public in this space and everything, several. But yet, you know, the need to kinda monitor, manage, see what’s happening is still here and I don’t wanna say it’s getting easier or—you know?
Spoonhower: [Laughter]
Shimel: Because I think it’s just, you know, natural. Things get more complex as we continue to build and so forth, and I guess that makes the monitoring easier, but when does it get simpler?
Spoonhower: Well, yeah, so I think the situation has gotten a lot more complex. That might be because of things like microservices or serverless or things like that. I actually think a lot of complexity comes from the fact that we no longer run our whole applications. Like, we use DynamoDB, we use third party fraud detection service, right? There’s a lot of pieces of our software that are not even ours any more, so that adds a lot to the complexity.
Shimel: Yeah.
Spoonhower: I think the simplicity has to come from focusing more on the use cases. Like, what are you as a developer actually trying to get done? And then, I mean—I think this is where people kind of get into things like AIOps is, like, using software to sort of harness the data that we have to help you in that task. I think that can be a real-really nice as a developer, right, to not have to understand all of the depths of what’s going on underneath the hood.
Shimel: Sure. I mean, I just find it somewhat ironic that, you know, we’re gonna break down silos, we’re gonna break up this monolith and go to microservices so that we can deal with smaller, more easily digestible threads, and then we’re gonna orchestrate all of this with a great tool like Kubernetes. And then I look at it, and I’m not the developer you are—I’m not claiming to be, or the technical person—but damn, it gets…it’s just the nature of the universe, at some level.
But anyway, you guys are well aware of this. It’s acute. This is the world you play in. You’ve got some new product announcements. Let’s talk about ‘em.
Spoonhower: Yeah. That’s right, yeah. So, I mean, the history of LightStep a little bit is that we started as a tracing tool, collecting data sort of—exactly to address the situation you’re talking about. You’ve broken your application into some pieces and you want to be able to understand the big picture, right, and put them back together.
And what we’ve done actually is to continue to integrate additional data sources into that, so that we can provide sort of more user-centric things. So, what we’re rolling out right now is a couple different pieces. One is error analysis, so being able to understand, you know, you have a spike in errors in your service, harnessing that data, whether it’s traces or logs or metrics, to understand what the cause of those errors are. We have a detailed rollout analysis, so even if you’re in the middle of a rollout, so you’re saying you’re gonna canary or blue-green or something like that and you wanna understand what’s happening, we’ll do that analysis for you and do a side by side to tell you what’s different about the new release.
And one thing that’s pretty exciting is that part of this is integrating metrics into the platform. Metrics are a tool that everyone has been using forever and ever and ever, but you know, there’s a lot of metrics out there, and part of what we think is important is that we’re able to focus on the right metrics, the metrics that are actually able to explain what’s happening right now.
Shimel: Absolutely. So, this new release, April 2nd, is the key day?
Spoonhower: Yeah.
Shimel: So, people listening to this can go check it out right now at LightStep.com.
Spoonhower: That’s right. We’ve got a free developer tier that you can try. We also have a really cool sandbox that’s sort of, it’s a sort of interactive playground where you can check out features and you can basically walk through one of these scenarios. So, say you’re doing a release, say you’re trying to debug an error or something like that. It’s not—you know, it’s not totally constrained, but will kind of show you along and give you a bit of a guide that you can still explore the rest of the product while you’re there, but really trying to help people kind of put two and two together and understand what’s happening.
Shimel: Yeah, no, I love that, man. Because I gotta tell ya, we’ve been experimenting with something like that for a project we’re doing on devopsy.kinsta.cloud where, you know, we want to have web people do a little bit more hands-on playing with different vendors’ tools and so, we’re trying to give them a sandbox, right, where they can go in and do these things.
Because, you know, we were talking off mic, right? Originally, this was gonna be an announcement around KubeCon which, unfortunately, you know, got pushed. And, you know, not getting into the whole politics and the whole thing around Coronavirus and all this stuff, but certainly, we need—we need more ways, we need more diverse ways of allowing people to see what kind of new products, what new technologies, how can they get it under their nails a little bit and really—
Spoonhower: Yeah.
Shimel: – kind of see if it’s for them?
Spoonhower: Yeah, absolutely. I mean, I think people learn in lots of different ways, right? Some people wanna read, some people wanna watch a video. I personally really like doing this stuff. Like, until I’ve made it, coded it, whatever, I never remember it, so.
Shimel: Absolutely. And you’re not alone. I do think specifically for technology vendors, having those kinda hands on that people can actually go in and we see it even on our webinars, man. If we do a webinar where the vendor’s doing a real live demo that people can follow along, we get insane numbers of people signing onto that, versus someone just talking, you know, and that doesn’t work.
So, let’s talk a little bit about what was driving this, for you guys.
Spoonhower: Yeah. I think, you know, we—so, I should say, when I say “we,” it’s me and one of the other Co-founders. Ben and I spent a while at Google, and Google—it’s a weird place, in a lot of ways, but there are some advantages. Like, there were ways in which being at Google is a little bit like seeing the future, and they weren’t called microservices at the time, but there were a lot of teams that built software that all had to stack together.
And we saw, you know, sort of firsthand the problems that they had in terms of like, okay, I’ve broken this thing into pieces and now how do I understand that bigger picture? We saw a lot of arguments among those teams, like, you know—“Oh, no, it’s your fault,” “No, no, it’s your fault”—and needing some data to actually kinda resolve that.
And so, I think, for us, you know, we saw the rest of the industry starting to adopt these things through different technology, maybe, but the same idea that you can have teams work independently and deploy independently yet still build a single application. And so, the motivation was really to try to help those folks to understand what’s happening and, you know, we see LightStep being used by individuals, but actually more and more by teams. We see it used in operational review so, you know, you’re doing a post mortem, you wanna show people what happened. LightStep is a great tool to help facilitate that conversation.
And for us, this is really about being able to help those folks deliver software more confidently and then, you know, get back to building new features and doing all the fun stuff that they’re doing.
Shimel: Yeah, yeah. I mean, wouldn’t it be great if we just, all we did was the fun stuff all the time? [Laughter] Some of us are lucky enough to do that, me included. But this thing, these are important things that need to get done and, you know, and LightStep is following that up.
I wanted to return to the KubeCon thing if we can, for a second, Spoons. Not KubeCon itself, but rather the Kube community, right? And you know, look, Kubernetes itself comes out of Google, right? I’m not gonna say the Google people invented microservices, but certainly a lot of very foundational work was done there, right?
When you are out and about or you see how this community has grown and the enthusiasm for things like LightStep, right—I mean, how does that, you know, kinda give you a warm fuzzy inside to say, hey, man, this is a whole—there’s this humongous community of people who kinda share our visions or our outlooks, and it’s a lot easier to sell to, and I don’t mean that you’re a salesperson, but it’s a lot easier to sell those solutions, right, than it is—you know, it’s not like pushing rope uphill.
Spoonhower: Yeah, yeah. I mean, I think [Laughter]—yeah, I mean, Kubernetes is a result of a lot of mistakes that were made the first time around. [Laughter]
Shimel: Yeah. [Cross talk]
Spoonhower: So, I think a lot of people would admit that. No, but I think the community is really great. I think the thing that’s pretty exciting to me about it is really thinking about things like infrastructure as code, about, thinking about automation, about—and, you know, these things which we kind of think of historically as, you know, maybe more of a craft actually can be an engineering discipline, and I think that’s a lot of that community. It’s actually really great whenever I’ve been to KubeCon to see the range of folks there from, you know, sort of platform folks all the way up to people that are just building features and shipping code, that they’re also excited about those tools. That’s really, for me, makes a big difference, just to see that it’s not a niche thing so much, right, that it’s really a broad community that’s excited about it.
Shimel: Oh, yeah, no, it’s broad. Me personally, I have 20 years in the security InfoSec space. I get excited when I see all the security people there about it, because I really feel like maybe this time we’ll do better, right? [Laughter]
Spoonhower: [Laughter]
Shimel: And we got out in front of this and where, you know, security is really kinda—it’s not the caboose on the engine, per se, it’s like, people care, and not just the security people care, the community cares.
Spoonhower: Yeah, yeah.
Shimel: And that’s important. So, you know, in today’s world, right, this isn’t this year’s release, this is just the April 2nd sort of new feature. So, what—and one builds on the next, right? So, what’s next here?
Spoonhower: Yeah, so, I think we’re continuing to think about how we can do automated analysis. So, we have a future in the product already called correlations which, essentially, you know, you pick out some effect you think is important, you know? Errors went up, speed went down, whatever it is, and LightStep will find the things that correlate with that within sort of the set of requests that you’re looking at. So, we have a bunch more features related to that coming out later this year.
So, this is kind of how I—I don’t know. When people say AIOps, I always gotta roll my eyes a little bit, but this is kinda how we think about, you know, bringing artificial intelligence to DevOps, right, is that it’s really through sort of putting the right clues in front of you, right? It’s not about providing 10,000 clues to solve a mystery, it’s about 5, right?
Shimel: Right.
Spoonhower: So, a bunch of stuff around that, and then—I mean, the other place that we’re thinking about is how do we get more proactive, right? How do we get in front of you and help you anticipate when these things are gonna be happening as well?
Shimel: Absolutely. So, I suppose one day you’re gonna grow old and you’ll be on this side when—so, I’m no longer building products or founding companies that are building products, and I hear public lands come up with all these…and I don’t wanna say it’s just some marketing term, but—
Spoonhower:[Laughter] You can definitely say that, that’s fine.
Shimel: You know, I will tell you, the first time I heard AIOps, too, I said, “What?” You know? But, you know, I’ve been in technology long enough where—look, just don’t call me late for dinner, right? I don’t really care any more what you call it. And also on the media side of it versus on your side of it, I just report the news, you know, theoretically, right? We don’t—if you wanna call it, you know, if it quacks like a duck and it walks like a duck, it’s a duck.
But in any event, I do hear you about that. And, you know, you wanna talk about an overhyped term? AI?
Spoonhower: Yeah. I think in the world of—in DevOps, I think it’s actually, there’s some—
Shimel: It’s overhyped, itself.
Spoonhower: Yeah, there’s some [Cross talk] though, I think, because you know, if you’re talking about, like, I don’t know, ad placement or something like that, no one really cares about why, right? Like, you put the ad and someone clicks—nice job, right? Like, good job, robots.
But like, you get paged and something’s like, “It’s that service over there, you should definitely roll it back.” And you’re like, “Yeah, but why?” Like, I’m not just gonna start rolling back things because robots tell me to.
Shimel: Yeah, “I said so, that’s why.”
Spoonhower: Right. [Laughter]
Shimel: [Laughter] But I hear you, man, it’s out there. Well, listen, I told you, the time goes really quick here, and I think we’re about out, man. But Spoons, it was great having you on here. Good luck with this new release. I would say I look forward to seeing you at the next KubeCon. Let’s hope there is a next—
Spoonhower: That’s right. I’ll see you somewhere, and if not, online.
Shimel: Yeah. Otherwise, we’ll have you back here on the podcast, man.
Spoonhower: Cool.
Shimel: Alright? Hey, that was Daniel Spoonhower, Spoons, CTO and Co-founder at LightStep. He was just our guest on DevOps Chats. This is Alan Shimel for Container Journal, devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chats. Have a great day.
Meet Steve. Steve is responsible for a mission-critical application for a very large enterprise. He has a problem: It takes Steve and his team a very long time to make changes to this application and release it to production. Steve has been talking to vendors, consultants and peers about agile software development techniques and DevOps, but Steve and his team have assessed that his application does not lend itself to these approaches.
See, the system Steve looks after is called a monolith, which is a very confusing title since it was developed using the latest modular software development approaches when it was created, in the latter half of the 1990s and early 2000s. Steve and his team are constantly advised that they need to decompose their monolith into microservices. However, this advice only confuses Steve and his team even more, since the system was designed using a service oriented architecture (SOA) with the intent of ensuring that it was easier to maintain and scale.
Steve’s team fell into a very common trap associated with many SOA-based designs: The services were designed with deep dependencies, they share a common database and they are very coarse-grained. Indeed, the collections service, which is one of eight services in the system, handles every potential operation a collections agent might ever need. Modifying any operation within the collections service means the entire collections service must go through regression testing and production must enact a very cumbersome deployment strategy that requires a five-hour maintenance window.
Needless to say, Steve cannot keep up with the requested changes from the business with these constraints. Steve’s advisers have given him some good advice on organizing to develop faster, but he would only be applying Band-Aids faster. However, once the constraints identified above had been pointed out to Steve and his team, they better understood the challenge ahead of them.
Steve and team are going to have to redefine the data models so they support service independence, then extract subsets of functionality out of the large, intertwined services to deploy as within a well-defined business context—following the “do one thing well” mantra. They then can start to extricate the complex business logic trapped inside the enterprise service bus so it can be incorporated into the services at the edge.
Steve and his team realize that continuing to enhance the monolithic code base avoids the challenges of redevelopment but reduces the value of that codebase to the business. While there will be a cost of untangling the monolith, the cost of not doing so is lack of competitiveness, lack of agility, long wait times for new features, possible opportunity loss and continued investment in technical debt. Steve’s job will be to present the justification for this to the business based on these risks.
When the task is completed, Steve and team will be able to deploy new services and modify existing services within weeks. The costs related to development and testing will drop significantly and the finer-grained services will allow developers to address business needs more quickly.
We’ll check in with Steve and his team as they embark on this journey and deal with the challenges ahead.