Separating The Noise to Simplify Multi Cloud Strategy with Leon Thomas of Jelecos

Transcript

Ledge: Leon, thanks for joining us. Good to have you here!

Leon: Thanks, Ledge! Thanks for having me. I appreciate it.

Ledge: Can you give a quick background of you and your work to let the listeners get to know you a little bit?

Leon: I’m the CEO of Jelecos, an 18-year-old company headquartered in Omaha, Nebraska specializing in helping organizations leverage cloud-based technologies. We’ve evolved quite over the years but, today, we focus primarily on AWS and helping companies both identify, strategize, migrate, optimize, and operate workloads in native U.S. environments.

Ledge: So what’s the primary industry focus? I know that Omaha has got a big financial services infrastructure. You deal with a lot of the security and on-prem-to-cloud migration-type stuff.

Leon: I wouldn’t say that we have a specific vertical focus but just the nature of our expertise and compliance puts us pretty squarely in that financial services market and heath care market. But we’re quickly seeing compliance requirements applied to almost every vertical in some capacity or another whether that’s ISO or SOX-type compliance reports. It just kind of depends. With PCI and anything compliance driven, there’s a pretty strong demand for that right now in our world.

Ledge: Yes. Nobody wants to be the next Equifax or whoever just released 15 million user records to the cloud. So I can appreciate the mandate for security. Going into the new year, I imagine that’s just going to be the exceptional focus. It must be a good time to be in compliance.

Leon: I think people also look at the shifting of workloads to the cloud as an opportunity to reevaluate how they’re accomplishing security and, subsequently, compliance. There are so many different ways to approach it that aren’t available with your traditional on-prem IT that it creates sort of a natural inflection point to reevaluate.

Ledge: How did you make the determination to focus AWS versus Azure? There’s Cool Cloud, too. Mostly, on the enterprise side, we’re seeing that almost all Azure and AWS are going to be in your small- and mid-sized companies just a little bit more on the market-penetration side.

How are the customers choosing or how did you choose to focus there?

Leon: That’s a really good question and one that we get often. The reality of it is that most of the concepts we’re working with are applicable to all three of the major cloud service providers. So there’s not a lot that we talk about that is only specific to AWS outside of maybe the individual services. Even then, you’re probably blurring some lines.

We’ve built our reputation on being really good at what we do; and when we looked at the three platforms probably four or five years ago, we knew going in that we had to pick a provider and develop deep domain expertise with that provider. We didn’t feel like we could do that across three different platforms simultaneously.

So when you take that approach and you want to put that level of depth behind the expertise, I think it was a pretty decision, at that point, because AWS was so far ahead of the rest of the pack.

And, clearly, there’s good competition, and that gap is closing a little bit. But from what we’ve seen, AWS continues to innovate and continues to grow rapidly and we haven’t had a need to really bring on any of those other providers in our services portfolio.

Not to say that we won’t some time in the future but, right now, AWS has been a great solution for us and for our clients. So we continue to ride that horse.

Ledge: The AWS re:Invent just having happened, they’re dropping eight, ten new services. It’s hard to even keep track of all the things that you could do. I don’t know what the service count is now but it’s in the hundred easily.

What are have hottest new ones? What should developers be paying attention to as far as competency around, at least, understanding what the options are in the stack particularly from a DevOps and awareness perspective?

Obviously, there is serverless and there are all kinds of other dedicated services. What do you see there? What is your advice for the developers set, things to be aware of in order to work with the best clients out there?

Leon: We have a good-sized team out there and several of our clients along with sixty thousand of our closest friends so it was certainly an announcement-packed event as it usually is. I think we’re up to a total of over a hundred and forty-five services. There were, at least, forty different feature enhancements on top of the new services that were all announced at re:Invent so it was a constant stream.

Sifting through the noise, sometimes, can be a little bit of a challenge. I think there are a couple of key things that came out for our clients and our team. On a maybe more infrastructure-related side, Outpost was probably one of the biggest announcements that they made allowing you to run AWS- related services on prem.

So that’s not available till Q3 so it’s not quite here but that’s going to be kind of a game-changer as it relates to hybrid cloud architecture as well as migration pathways. So there are some different implications for that announcement that will be pretty impactful to the industry.

A couple of other ones key on the infrastructure side again, the announcement of Deep Archive which is a storage tier that is even lower cost than Glacier that’s, essentially, a dollar per terabyte per month for archive data that makes Tape look pretty dumb right now. And there is still a very large portion of the people who are running Tape for some of their archive workloads. So that’s another one.

Intelligent-Tiering is another one that is a big deal on the infrastructure and storage side as it relates to what we do.

On the more development-related side, I think pushing Lambda to the edge continues to be a really hot topic right now and something that we’re seeing some developing use cases. Some other best practice around Lambda layering and custom runtimes are big things from a development standpoint in our eyes.

I think you’ve got continued improvements to the development toolset and to the CI/CD pipeline toolset that are going to make it a lot easier to do full CI/CD automation.

Additional support ─ I already mentioned custom runtimes on Lambda. Another real hot area that we saw a lot of movement in was around data lake with the new data lake formation service that really simplifies that deployment as well as the improvements to SageMaker and just general machine learning capabilities across the board.

The ability to pull some of the different machine learning models directly from the marketplace changes the game for a lot of the data scientists who are out there and a lot of the analytics/ML projects that people are able to get to with a very low cost of entry or low barrier to entry compared to what it was even twelve or eighteen months ago.

And then, finally, I’d say that it’s probably not an exhaustive list but the other one that is high on our list is just the general improvements to containerization, the continued expansion, Kubernetes capabilities and just Fargate, in general. We see those as really good options for some of our clients who are doing application modernization.

And looking at even cloud-native development but modernization tends to lend itself well to that.

Ledge: Talk about application modernization. I think that’s going to be a huge topic particularly in the next two to three years. The opportunity becomes more ripe for legacy applications to go to the cloud.

Now, you have many enterprises that are probably going to be pretty excited about containerizing .NET Core or things of that nature running it on Linux containers, and that makes a lot of sense in the vast improvements in performance.

Do you see a lot of legacy applications being re-thought into the more modern JavaScript maybe Node-centric types of development patterns?

Leon: Yes. For all sorts of reasons, we recently completed a project where there’s a large scale e-commerce environment that had developed sort of an internal microservices architecture using more of the traditional monolithic stack; and the functionality was spot on but there was no way to scale that to the level that they needed it to scale. I mean, it was a long ways off.

Moving that into more of a serverless architecture with sort of a scalability pathway that’s a pattern that is pretty much automatic is a game changer for those guys. It minimizes cost; it minimizes overhead and maintenance; and it allows them to scale very rapidly and reduces all that overhead.

So we see that. I think the other thing that comes about even if you look at ─ you’ve got your traditional monolithic tier or three-tier applications that have some really significant challenges in scaling that moving to a more of a serverless architecture wherever possible within the application allows you to decentralize some of those constraints and scale accordingly.

The other thing we see is this whole concept of right tool for the right job and getting away from focusing on this monolithic underlying commercial database where we can choose the right database for the job.

If you look at mainframe and midrange-type systems modernization, I think you’d have to rethink how that’s done with Lambda, and custom runtime. You can now do that in a number of different ways.

As we look at organizations that are migrating legacy applications, there is almost always going to be some refactoring that needs to be done. The AWS talks through this concept of minimum viable refactoring, and that’s making sure you’re only investing where you’re going to get a return whether that return is better performance with better reliability or lower tool custom operation.

I think the concept of simply rewriting the whole application is overkill. It’s how we do the least to get the most value and move on to the next set of workloads.

Ledge: I’ve had it described to me by other tech leaders as “pragmatic microservices” which I thought made a lot of sense. It’s not the smallest chunk that you could ever possibly do. It’s breaking it into meaningful chunks and then seeing which ones you need to hammer on and break those down into smaller chunks.

Do you have any trouble convincing clients that this sort of ongoing work, this leaner experimental-type of work is not the same as when we used to engineer a giant monolith and let it run for twenty-five years and got us into the problem in the first place?

This is a constant thinking pattern and it really changes the culture of the organization as well.

Leon: That’s a really good point. Generally, we don’t have any trouble with the actual decision to do the work because it becomes a very objective cost equation that is, “Okay, if we do this, it will cost you X and save you Y.” So that part of it is pretty easy. But we don’t even usually get to that conversation until the light bulb has gone on you. You’ve sort of broken through that cultural component.

One of the things that we tell organizations is we’ve been trained over our entire IT career to make three- to five- to seven-year decisions. So we need to force ourselves and the organization into making three- to five-day or three- to five-week decisions.

You can now do this. And if it works, great, you do more of it; if it doesn’t work, you shut it off and you take a step back and you spend a dollar and twenty and you do something different.

So to your point about the pragmatic microservices, it’s very easy to over-architect the microservices architecture especially when you’re trying to replace or modernize a legacy application.

We recommend approaching it very iteratively and, as you’ve said, just hammering on the areas where you’ve got contention or the areas where you have reliability or scale challenges just in general.

Ledge: This is the last question I love to ask everybody. We’re, obviously, in the business of sourcing and evaluating and vetting very high-end engineers and we have a multitiered, very extensive process for doing that. It’s hard to get on the bench.

Yet, we recognize that there are best practices all over the place. So I’d like to ask every tech leader that I talk to, “What are your heuristics for evaluating and finding the very most senior excellent software engineers to bring on to your staff?

Leon: Yes, like any good services company, we have a number of different pipelines in terms of talent from internship-type opportunities all the way to very senior candidates that we look at.

And we work with a number of different organizations to get that done some of which take care of some of that early evaluation process on our behalf. Others are more of a traditional model where we’re handling all of that screening upfront.

The first thing we look at is business acumen because when you’re looking at convincing/helping organizations understand moving to cloud and when and how to do it, this is no longer a subjective conversation. I mentioned before that if you do this, you will save this or it will cost you this amount.

So regardless of your role in our organization, it’s really important that you understand the business impact of what you’re asking or what you’re doing on behalf of our client.

That’s where we start, Ledge; and, from there, obviously, we have our team go through a pretty extensive vetting process and we like to do situational conversations around “What would you do in this situation?” or “What have you done in this situation?”

We look at certifications just like anyone else. They’re important to us for a number of reasons and we trust the AWS certification process. That pro-cert is not an easy thing for people to get unless they have actually gone out and done the work. So we think there’s some integrity in that that we can count on. And with our focus being AWS-related consulting work, we hang our hat on that certification today.

You’ve got to have business acumen and you’ve got to be a good cultural fit because we’ve got to work as a team, and they’re usually small teams. And there’s no room for the old-school “sit in the corner and do my job and don’t bug anybody.” You’ve got to be able to look at the whole stack and, at least, appreciate it for what it is even if you are focused on one end or the other of the stack. You’ve got to understand the value of all the different layers.