Fads vs. Business Needs: How Should Non-Technical Leaders Navigate Engineering Decisions?
Monolith or microservices? Which should you use and why? I'm Max Clark and, let's get into it. Last year in 2023, Amazon Prime Video Tech released Amazon Prime Video releases a tech blog talking about how they have re architected their video pipeline with a monolith. And they are saving a fortune in the process of doing it.
Speaker 1:It's better, it's faster, everything is is is ideal, and they're saving a ton of money. Week or 2 ago, Netflix releases a blog post in their engineering blog talking about how they've just completely re architected their video processing pipeline with microservices. And it's awesome, And it's amazing and it's the best thing since sliced bread and it should do it. And and if you've been involved for for tech for any amount of time, the monolith versus microservices architecture argument is not new to you. So I'm not gonna focus on pros and cons of 1 versus the other.
Speaker 1:I'm gonna focus on which you should run and why you should run it. And I'm gonna start off by saying it depends. And it depends on what you actually need and why you need it. The arguments for one doesn't invalidate the reasons for the other. And you can have of large teams coordinated on a single code base in a monolithic application and scale.
Speaker 1:You can split up your teams into different into different groups, into different pipelines and use microservices. If you are operating a business at Netflix or Amazon Video or Uber Scale, you're gonna have an engineering team that is going to be in charge of these decisions. And they're going to be giving you solutions hopefully that actually meet what you need. Right? So this we can get into like TypeScript versus native JavaScript arguments.
Speaker 1:We can go a little bit deeper than this and talk about typing strongly typed languages versus non strong strongly typed languages. And why at certain points in in iterations you have to get into a strongly typed language. I mean these these are all like, this is not new. This is stuff that's been going on for a long time. Now I probably should actually talk and focus on what the actual core of this is.
Speaker 1:And if you're a non technical leader, what's actually happening under the scenes with your technical team. A lot of engineers are going to try to solve problems that aren't actually problems or they're gonna solve problems they shouldn't be focused on solving that they shouldn't probably even address in the first place because it doesn't actually matter to the business. Engineers get bored, they wanna play with new things, some new hotness comes out and that new hotness needs to be played with. And this is where you get conversations around when you refactor our code base, we have too much tech debt, we need to migrate from this thing to the other thing. And that's usually the sign of a an engineer that's bored with a lot of a d d probably in terms of like, oh, new shiny object, let's go play with it.
Speaker 1:And I mean, what's what's great. Right? So Ruby on Rails came out, it was the most awesome thing, everything had to port to it. Then Node. Js came out, then that was the most awesome thing.
Speaker 1:Everything had to port to it. Then you've had express versus sales versus react versus view versus this versus that, which which kinda kept everything in the in the Node. Js ecosystem, but then you had what framework you were using on top of being changed and flipped and pulled out and and and iterated. And then go comes out and it's like, oh, we've got a port from Node. Js to go.
Speaker 1:So if you got people that are telling you at those sorts of intervals that you need to drastically rip and replace entire pieces of your infrastructure, you should evaluate your teams and why. By the way, this isn't related it is specific to software. I've seen it in the hardware too. I've had conversations where a company has hired a new leader in their technical teams and that leader has decided that they're going to get rid of their data centers and move everything into AWS or GCP. Why?
Speaker 1:Well, probably because they we used to work for AWS or GCP. So if you hire somebody to be your CTO that was a GCP person, guess what? You're migrating your infrastructure to GCP as quickly as that person can do it. Same thing. If you hire somebody who's a Aldi's PHP disciple and you're running a Node.
Speaker 1:Js environment, just just just understand that you've made the decision by hiring that person to move your environment from Node. Js to PHP. What's another example of this? New service provider. Very large infrastructure, nationwide network and they hired a a new VP of in of engineering for this for this network.
Speaker 1:And and I was talking to this person and this person had told me that they were in the process of planning a rip and replace of all their Cisco gear for Juniper because quote, he didn't like Cisco and Juniper was better. Now if you're hiring somebody because you wanna do a rip and replace of 1,000,000 of dollars and 1,000 of boxes, like, fantastic. That's a great that's a great argument. When you when you talk to people leading mature, stable network backbones, they look at these things very much very differently. Right?
Speaker 1:To a certain degree, we'll we'll stick with Juniper and Cisco. The difference between an ASR and an MX is almost irrelevant to them. They're just boxes. And their configuration management and their provisioning systems and their monitoring and maintenance and and all these things can interchange one box with another box. And it's just what's the best box for what we need at that point.
Speaker 1:And you might see iterations and and evolutions. We use this platform for our 10 gig rollout. We upgraded our entire network to 10 gig on top of, I'll just say Juniper, Juniper. And and then as we were planning our 104 100 gig rollout, we decided and realized that we could get a better better performance density by going to Cisco. Right?
Speaker 1:So we decided to do our whatever upgrade to Cisco. Now, most of the time then they'll say the next upgrade maybe they go back to Juniper or maybe they introduce somebody else. Nokia got very popular with the European pein peering exchanges. Why? Because they had very low latency and very high port density of the very fancy fast ports that people needed and and you switch.
Speaker 1:And I would make the same argument to you in everything else. Is there a deficiency that you have? And is it really a deficiency? Or you just is it just shiny object syndrome? Are you staring at your neighbor's lawn and wishing that you had greener grass?
Speaker 1:And I'm gonna tell you that the grass is not greener on the other side of the fence. It's just different. There's different requirements that you have to get into. Managing a monolithic application is different from a microservices application. They have trade offs.
Speaker 1:They have big trade offs. Do you understand what those trade offs are? And are you making an a decision and an argument based on those trade offs? Or you're just making a decision based on somebody told you, hey, we need to do x, y and z because of blank. Right?
Speaker 1:By the way, the other scary thing about these sort of changes, and I don't care if it's software, if it's if it's architecture, if it's on prem versus cloud, cloud versus on prem, if it is vendor a versus vendor b of hardware, I mean anything. Right? Service providers. You have to consider and think about the cost and disruption of switching. Right?
Speaker 1:So since the first time I saw it which would have been 1990 actually 1999, I believe it's 1999. I was working for a dotcom and the dotcom hired a new CTO. And the new c t o came from a background of Oracle database and Java application servers. And so, the c t o decided that the entire infrastructure needed to be reimplemented in order for it to be scalable and and and reliant and yada yada this and that next thing. All the buzz words that you wanna talk about, we had to completely reimplement the entire environment in with an Oracle database, with BEA WebLogic and your standard stack at the time.
Speaker 1:And he kicked off a a almost like a skunkworks project. We hired engineers, a lot of them by the way, and put them in a different office, and they started a process to rewrite the entire environment from scratch in this new modern architecture that was going to, save the day. Now by the way, the old architecture was Microsoft SQL Server running on Windows and T 4 Servers with ColdFusion. It was a ColdFusion application server. And I will tell you that the ColdFusion code base with a Microsoft SQL Server back end outlasted the CTO.
Speaker 1:Because when that was pushing 2 years and that hadn't ported off and they had burned lots of licensing money, lots of engineering overhead and lots of time. Now fortunately in this case, the cold fusion team was still charging along and implementing delivering features. That way the sales team and the business could actually execute and generate revenue. Wasn't horribly disruptive. It was it was expensively disruptive, but it wasn't business critical crippling disruptive.
Speaker 1:But that I see and I have seen a lot. I've seen a lot of times where somebody comes in and makes some edict, hey, we're going to switch from a to b and the business goes is paralyzed and sits and stagnates for a year plus. And then that person either finds a greener pasture and leaves by themselves, or maybe they are finally asked to leave because they're not actually creating any enterprise value for the business. So which is right for you? I don't know which is right for you.
Speaker 1:Well, hopefully, your teams know what's right for you. And if and if your team is advocating for a switch, make sure you understand the switch and the trade offs. How long is it gonna take? How expensive is it gonna take? What are you getting at the end of the day?
Speaker 1:How do you how do you temper and and minimize your risk in the process of that? We haven't really talked about risk, but how do you minimize your risk in the process of the change? Do you have to change everything or can you just change a piece of it? I mean, by the way, great thing about Node. Js and and Go is you can slot it in on specific API endpoints.
Speaker 1:Right? Like you can derive a specific section of your application via this other thing without porting all of the application over to it. Right? You don't have to like do a wholesale rip and replace. You can rip and replace.
Speaker 1:You can replace a piece of it if you really need to. And and these are perfectly fine things. I mean, I wouldn't call myself a software engineer ever. Early 2000, I helped a company replace a struggling PHP application with mod pearl and we changed an API endpoint. There were a lot of things that that made this the success story it was.
Speaker 1:We took infrastructure that was running on 20 servers and struggling and and turned it down to 3 servers and it was screaming fast. But it was just that endpoint that was driving a section of the application business logic. And solving that problem solved the big scaling point for that business, and and they were able to get back to growing their business. So it's this isn't a one size fits all thing, and try not to fall for that trap. Try not to fall for the Cisco is better than Juniper, Juniper is better than Cisco.
Speaker 1:You should run BroadSoft. Oh, you need to run Broadcom. Oh, you should be running Juniper or sorry, Fortinet versus Palo Alto versus this versus the next thing. And they're very easy. I mean, us, I'm a I'm a tech nerd.
Speaker 1:I get it. We love to sit and and talk tech and debate the pros and cons, the merits of 1 versus the other, and and why you should run 1 versus the other. And one is better because of these reasons, and I like this one better because of these other reasons, and then this one sucks or this one's great or whatever whatever it is. This is what we do. We we get together and we talk about these things.
Speaker 1:And then we write skating Twitter recent posts and and make videos about it. But back to the things, the important thing is, what is the business doing? What does the business need? Are you at a point in the iteration of the business that is being constrained by the existing technology, and how do you solve that? Okay.
Speaker 1:Great. How do you solve it? Now as a closing parting thought here, I have seen this done where companies introduce new application programming languages as a way to attract technical talent because they have a hiring issue. Hey. Our main application is written in PHP.
Speaker 1:We can't find people to hire into PHP because nobody wants to code this anymore. We just don't know how to find them. So let's decide that we're going to start coding in Node. Js because then we're gonna be able to find Node. Js programmers.
Speaker 1:And I don't really know if this is a good strategy or a bad strategy. It's good in the short term. The problem with that strategy is a lot of those programmers that are going to come over and work for you because you've got a Node JS project, when the next thing comes out, those are the same people that are probably gonna be going to go play with that next thing or advocating for you to ditch what you're doing and switch that new best thing. So this comes back again. Beware of the shiny object syndrome.
Speaker 1:Be careful, I mean, I love reading technical blogs. It's great to read why Prime went to a monolith and what it did for them and what their learnings were, and it's it's fun reading why Netflix just changed their mic microservices architecture. But if you've got an existing code base in Rails, or an existing code base in Django, or an existing code base in PHP, or you've got a whatever it is, be really slow to commit to throwing that code base out. And spend some time to really understand and evaluate, do you actually have a deficiency that you should address? Or can you just change your operations a little bit?
Speaker 1:Or how you are addressing it? Or what you're doing? What are you trying to get to and why? And if you think about it from that standpoint, what are you trying to get to and why you're gonna be better served in the long run? I'm Max Clark.
Speaker 1:I hope that helps.
