3Pillar CTO Jonathan Rivers Talks the Future of the Tech Industry

3Pillar CTO Jonathan Rivers gave his view on where the tech industry is going at Product Matters, a product-development focused event that was held on September 7^th in Iași, Romania as part of the opening of 3Pillar’s new office there.

In the presentation, Jonathan shared his views on the technology trends he sees shaping the future of digital product development. Microservices and cloud-forward builds are 2 tech areas that Jonathan believes will come to dominate the landscape when it comes to building web-scale products. Visibility, efficiency, and flexibility are three attributes Jonathan identifies as vital for any development team to be successful.

Specific recommendations Jonathan has to ensure visibility, efficiency, and flexibility include:

• Application performance monitoring, via tools like New Relic or AppDynamics
• Distributed tracing, which gets to be necessary to troubleshoot problems when you have applications that are comprised of 50, 75, or even 100 microservices
• Centralized log aggregation so the development team has one view of any issues or problem areas that may arise as applications grow over time

Watch the Talk

Interested in hearing more of Jonathan’s take? You can watch the full video of Jonathan’s presentation below.

About Jonathan Rivers

Jonathan Rivers is the Chief Technology Officer at 3Pillar Global. In this role, he leads 3Pillar’s Product and Engineering organizations. This includes more than 800 software engineers, product consultants, product managers, quality assurance, and user experience professionals. He has 20+ years in System Administration, Data Center Operations, Cloud Infrastructure, Orchestration, and Automation. Before joining 3Pillar, Rivers was the Interim CTO at The Telegraph of London, where he served as Director of Service Delivery and Operations before becoming Interim CTO. He was part of the leadership team that transformed PBS into a digital leader as their Sr. Director of Web Operations and Customer Support.

About Product Matters

“Product Matters” was the first 3Pillar tech event in Iasi, Romania. The conference featured presentations on recent technology trends and understanding how teams work together to better manage the product development lifecycle. Attendees were also taught the Product Mindset during the conference.

Read the Transcript

Howdy y’all. I will actually apologize in advance. I am Texan and do say things like howdy and y’all. I can’t help myself. It just really goes with who I am. The only thing that I love near as much as motorcycles, and I am that crazy with them, is technology and building internet-grade software.

Here at 3Pillar, it’s the perfect job for me because instead of getting to build one thing, I get to live vicariously through over 100 teams building 150 different product lines. I get to work with our sales organization and talk to five, 10 different companies a month, figure out what they’re building, what they’re interested in, what their problems are, what they’re trying to solve. It really gives me a pretty broad sense of what’s going on in the marketplace.

I just recently realized when I was talking to our product folks that we do, on average, over 2,000 retrospectives a year. That’s a lot of learning. That’s a lot of chances for improvement and figuring out what the next things to build are. I thought it would be fun to talk a little bit about what’s going on in the marketplace. I think I get lucky because I’ve got a very broad view and get to see a lot of things happening at once. I wanted to go ahead and share some of that.

As we go out into the market, there are two main things that I’m hearing and seeing all over the place. The first is that there are a huge number of startups, first-time builds. They’re starting from the ground up. They’ve got an idea, “What should I build? What should I use? How should I build it?”

The second is that all of the old companies that built something very, very early on are getting ready to re-platform. One of the things David talked about is software never being done. There are a lot of people out there who are like “I spent $200,000. I’m done. I don’t have to spend any more money”. It’s five, seven, nine years later. They’re running ColdFusion. They regret it, and they’re figuring out how are they going to get back in the game and stay competitive.

Now, with that in mind, both sets of those people are really doing it in the same way. It’s with micro services and cloud native builds. I think it’s essential to both of them. Micro services are really not only at the forefront. It’s what everybody is doing and really going with. They are fantastic for companies to be able to see value.

As people start building software, they go sprint after sprint after sprint. “When am I going to see something? When am I going to be able to see something working?” Micro services allow you to break things into smaller components. You can have a user login system really, really quickly. You can have a profile system really, really quickly. It’s easy to show something done.

For any of us who have to deal with businessmen on a day-in day-out basis, we know they like things are done or something that they can see marked in a green status on a dashboard. Now, that’s combined with the ability to do parallel development. You can take ten modules. You can give it to ten different teams and have them all make progress at the same time. You’re not exactly running into the mythical man-month that you really do with larger monolithic applications.

Then finally, it’s just good design, right? It is more resilient than these big monolithic applications because you can have a component fail. If your user login system fails but everybody can still get content, you’ve got a much smaller problem than the entire site or the entire application being down.

This is backed up with cloud native architecture, right? I fundamentally believe that cloud design is good design. Loosely coupled components that are independent of each other are really the way to go. You see that with it having a much lower barrier to entry. You can go plug a credit card into Google, into Amazon, Azure if you’re into the Windows stuff and get started for pennies on the dollar. You don’t have to go out and spend large amounts of money on hardware.

You don’t have to figure out much hardware you’re going to need. You’re not going to have to figure out any sizing exercises. You can just get started. All of the cloud setups are developer-friendly. They were designed that way.

If you look at Amazon very, very specifically, it was never designed for IT groups and never had the support tools that an enterprise organization would need until the last couple of years. It started with developers first and foremost, and it’s still going that way.

Then finally, you get a lot of stuff for free. That’s not free as in a lack of money, but they have a lot of services. You can get a big data warehouse. You can get EMR. You can get RDS or databases or memory caches without having to set up and run the infrastructure. It means you’re going to have a lot less IT overhead or ops overhead than you would if you had to build and run all of that yourself.

Both of these are really attractive to both sets of customers. Frankly, those people who are coming late to the game, five years ago they were calling and saying, “I need to add three new drop-down boxes to check menus and a new banner unit”. They’re not extending the application. They’re figuring out how can they get out from under this thing and rebuild it in a new fashion. It’s really what we’re recommending and what we like doing.

Talking about technology trends overall, they really are falling into three areas that I’m seeing time and time again. It’s worth noting the first is visibility, the second is efficiency, and the third is flexibility. In terms of visibility, years ago I was building the cloud infrastructure for PBS when I was a client at 3Pillar. We had a large-scale video portal that was putting out about two to four petabytes of video every month. It’s a significant amount of video.

We were having problems with buffering issues. We were using Amazon’s cloud-front CDN service at the time. They could give us no metrics. I called them and I started yelling at them. I was really, really upset, and they took my side. I thought they were going to argue with me. They took my side.

They gave me a quote that they believe in. It’s up here, and it has actually changed the way that I operate all of my teams, all of my products. They told me, “Without sufficient information to prove otherwise, all customer complaints have to be assumed as true”.

Now, that’s a pretty customer-centric thing to do and odd for an IT organization. They’re not like, “No, I don’t see any problems. There are no red lights, no red lights. It’s fine”. They went above and beyond to try and track these things down because they didn’t have enough information to tell me that they weren’t causing my buffering problems. I think the marketplace is starting to catch up with that train of thought.

With that in mind, you’re really seeing a lot of the companies out there invest very heavily in one of three areas depending on their particular level of sophistication, their application and where they are in the process. The first is application performance monitoring, things like New Relic, App Dynamics.

It is so much easier to have a server-side agent that is telling you which thread is causing a problem, which SQL statement is actually taking a long time to run. You’re no longer getting developers poring over thousands of lines of code to guess where a performance problem is. It’s telling you right there in a web interface that everybody can look at. It’s hugely impactful.

The second, distributed tracing. Its super bleeding-edge, but I’ve probably talked to five or six customers in the last three months about the need for it. As these micro service architectures evolve and people start getting a little crazy, we’re seeing things with 50, 75, 100 different micro services all combined into the same application.

It starts getting really difficult to tell why you have a slowdown. Where is it breaking down? What’s happening in that chain of contiguous services that is causing my trouble? I’m a big fan of open tracing. There aren’t any good standards out there yet. It’s really evolving, and everybody’s going to have to build this as they go along. I think over the next year this is a space that’s going to get super hot.

The third and the last, and I thought it was common. It should be common. If you’re not doing it, I highly recommend it. Centralized log aggregation is huge. The ELK Stack, Elasticsearch, Log Stash, Kibana, really, really great way to centralize all of your logs and make sure that everybody has access to it. You can set up alerts, start understanding your application state.

Again, you’re not logging into each individual server trying to figure out which one is bad and solve a problem based on error messages. You’ve got everything in one interface where you can consume it all very, very quickly. I think, again, visibility is key as these applications get bigger, as they become more sprawling, as they take on a huge real estate. It’s necessary.

The video portal that I was talking about is comprised of about 15 different services. That entire ecosystem runs on over a thousand EC2 instances backed up by about 200 different databases. Now, if you think about how you’re going to keep something like that running, you probably need to be able to see into things very, very quickly because at that scale you’re not really going to be able to know what all’s going on.

Talking about efficiency, and this is something I end up talking about a lot. I spend inordinate amount of my days talking about velocity because everybody comes to me and they say, “How can I get more velocity out of my developers?” Anyone hear that, “How do I get more velocity, more speed? How do I know if my developers are actually working fast enough or at full capacity?”

I usually tell them that they are. Velocity isn’t your problem because velocity is not about speed. Velocity is about consistently, can we consistently estimate the size of a story? Can we have a common shared language about how long things are going to take? Can we do that repeatedly, sprint after sprint?

Do we know that something that’s four story points takes two days or something that’s a medium takes five days? Can we do that time and time again so that businesses can predict when the software is going to come out the other side?

When we talk about velocity and efficiency, I always tell them, I’m like, “You’re probably trying to solve for something else. It’s not that your developers are lazy. It’s not that they’re off playing foosball too many hours of the day. It’s that you’ve got a problem that somewhere between when the code is checked in and when it actually hits production where it’s in the hands of your customers providing value. There is some friction there that is slowing everything down. That’s what you really need to look at”.

I think there are three huge trends that are backing up that movement that people are really starting to move to. The first is DevOps. It is near and dear to my heart. I spend a lot of time yammering about DevOps. I’m a huge proponent.

I thought it was mainstream. I was here in Romania. I was in Cluj and Timisoara speaking at our DevOps conference. I was surprised at the number of people who came up and asked me, “How do I convince my boss to start doing this?” I had thought it’s common. It wasn’t.

Build chain optimization is the number one place to really start helping velocity. Do you have a good CICD setup? Can you improve the amount of time from when you submit a build to the time that it gets to production? DevOps is really focused on getting all of that done.

The second is server-less technologies. They are becoming more and more common. You start looking at things like Amazon’s Lambda. The ability to run code directly, natively without having to deal with any infrastructure is huge.

We’ve just recently set up for a client a full setup that is 100 percent server-less. It uses code pipeline, code deploy, straight to Lambda so developers can submit straight in, run into production, test. There is no friction in that environment and so nobody’s asking questions about their velocity as a result.

It’s interesting that this is coming out. A couple of years back I was at Amazon’s Reinvent conference. Reed Hastings, the CEO of Netflix, was complaining about still having to decide how big of a server he needed. He was like, “Why should I care if my server’s a medium or a large? I just want my code executed”.

That was 2012. I think five years later, we’re starting to get there. It’s not for everything. It’s event-driven. If your application isn’t particularly event-driven it’s not going to be super successful for you, but it is starting to come primetime.

The third is QA automation. I just can’t stress QA automation enough. It’s finally starting to win the war against manual testing. I recommend it for everyone. Don’t get me wrong. Manual QA has its place. It is unbelievably important. You can’t beat high-value exploratory testing to figure out those weird things that your customer is going to do that you never thought of. It’s still valuable, but automated testing is incredibly important for creating consistency and improving velocity.

The higher your test coverage is when you actually submit code, the faster you’re going to find problems, the less friction you’re going to have, the less redeployments that you’re going to have coming back because there were bugs found in the code. It’s hugely, hugely impactful.

The third, when we talk about efficiency and we talk about cloud, you can probably tell I’m sort of a cloud guy and that I absolutely adore it. I ran a data center for the better part of the decade. If I never have to do that again, it will be too soon. The cloud really is not a place. It’s a state of mind. It’s a set of design parameters and it’s things to start thinking of, again, those loosely coupled components, the notion of impermanence.

It’s a big shift in the IT community and software development in general. The notion that believing and designing your applications, that your servers could go away at any minute is crucial. I see time and time again. People pick their applications up, put them in Amazon just like they were in the data center and not be happy with the results. It’s slow. It still fails. All this stuff that they told me the cloud was awesome for, I don’t see.

It’s because they didn’t redesign it with this notion of impermanence, that anything can go away at any time and I need to be prepped for that. We’re starting, as a result, to see a number of things that are helping with that go much, much more mainstream these days. For a lot of it I’m super excited.

The first, the notion of full-stack development teams. Even from the extreme where you have full-stack developers supported by QA automation and DevOps all in the same team. You have the team that builds a thing runs a thing, is really starting to happen. We’re seeing more and more products being done on the mean stack. It’s a great way to have a very contained ecosystem that all of your developers can manage.

When you start thinking about your backlog, having all of your developers being able to take tickets against it is incredibly valuable. Can you set your application and your teams up to do that and break down the barriers between “I’m a front-end guy”, “I’m a back-end guy. I only want to build APIs. I only want to build really slick single-page applications”? Having more functional developers is good for everyone.

The second is containers. Five years ago, I was not a huge, huge fan. I think, like the last two technologies I’m going to talk about, they’ve really become mature. They’ve really become primetime. The containers and their schedulers are good enough that they’re ready for production. This allows your workloads to be so much more portable and to get rid of overhead. It’s vagrant and dealing with VMs.

Big applications don’t work well on that. You need way too much memory to be able to set things up. Docker and Kubernetes really allow you to create production-like environments on a laptop. You can deploy from a public cloud to a private cloud to somebody’s laptop. It gets rid of the “It worked on my machine” and makes code that much more portable. It’s really worth looking at for your applications or investing in.

Then finally, the JavaScript frameworks. I will caution everyone to avoid resume-driven development and chase after the latest and greatest JavaScript framework that’s out there. A lot of them, React, Angular, have become very, very mature. They now have that functionality. Again, when you’re dealing with micro services or single-page applications, they’re a great way to stitch together a number of services into something clean and attractive.

Even things like React Native have gone primetime that are starting to blur the line between a mobile developer and a front-end developer. If you start thinking about flexibility in your teams and how can I have more people have more of a hand in developing my process, being able to do an iOS build as well as take tickets for the desktop version of the application is hugely impactful.

It means your teams can concentrate, that you don’t have all of these skills, that you’re only getting 40 or 50 percent of their time utilized. That’s where a lot of those conversations about velocity are coming from because maybe there’s not enough work for them or you’re having to move your backlogs around and tickets are waiting because your back-end guys are way ahead of your front end guys.

Really, moving to a lot of these full-stack and shared services gets you away from that where you’re combining workloads when and where you can.