Digital transformation and the right tool for the job with Dan Morgan of Unitas Global

Transcript

Ledge: Dan, thanks for joining us. Why don’t you give a quick intro of yourself?

Dan: Sure. I’m Dan Morgan. I’m currently with Unitas Global working on my second year here. I have been in the development scene now for about twenty years. I spent a good chunk of that as a developer ─ I’d say half of my career as a developer. And then, I had some flirtations with leadership as a developer leader. I took a director role four years ago now and have been leading teams ever since.

I got a lot of interest in how we get development done now and moved away a little bit more into actually how we code it and more how we get it done.

Ledge: So what’s the nature of the work currently now as you’ve taken a leadership position around software development? Obviously, you’ve got teams you’re deploying.

What kind of projects you’re working on? What kind of demands are you seeing on the field?

Dan: With this team, specifically ─ and I’ll do a compare/contrast with my previous job over at Load Delivered which is really an equally cool opportunity ─ what we have here is we’re using containers. So we’ve decided to go all in on the container thing. We haven’t really moved in to serverless yet.

We decided to go with containers which led us down the road of actually learning about the dif

ferent technologies ─ Kubernetes, Docker, ECS ─ and looking at those technologies and developing in that realm.

So everything that we do is a micro service now. We’ve got some less success

databases in containers. I can tell you about that.

Yes, it has been a really interesting experience trying to really move into that layer of containers which then plays into DevOps and all sorts of areas. You can really take it any way you want to go.

Ledge: Absolutely! Obviously, containerization is huge and orchestration of that kind of architecture. I’ve done a lot of work talking about micro services and sort of the domain-driven design around doing that the right way.

We would be interested to hear the perspectives, for sure, on the database management through containers. What have you discovered there because that sounds like a good story?

Dan: Yes. We’ve had less good experiences of putting databases on containers. It’s just some interesting tool in your shoes. I think it’s funny. There’s the old joke that if there’s a new technology, the classic is “Doom on it.”

“Hey, a new printer came out. Can you run Doom on it?”

The same seems true with technologies, with databases, and other kinds of things. I remember when containers were first introduced ─ and containers are not a new technology for anybody who’s not aware of that. It’s really just keeping the scope of the operating system on the spot.

What we thought that was really interesting is “Can you run a database on it?”

No, no, no!

And, of course, as soon as you say no, you can’t, a bunch of developers try to the point where, fast forward to the year ago, we were tasked with our SQL Server instance that they wanted to run and they were going, “Oh, you know, we’ll just run it in containers.”

You’re on Docker so that means that everybody at the company, every developer is running Docker instance. We’re on SQL Server and we don’t have to worry. It’s all there.

It turned out that we had some serious problems with deployments with keeping everybody’s copy of SQL Server in sync. It didn’t seem to behave quite the way we thought it did.

So points to Microsoft ─ they got SQL Server running in Linux and they got it running in container.

But we found that it was a lot easier, super easy to script. We were able to script up SQL Server loads with our DevOps pipeline. We were able to do a lot better work as soon as we shifted all of our databases over to just be regular instances running on the hosted google instances.

It’s cool that you can do it but we found that that’s just one area that we were getting advantage and it runs better so we switched back to using traditional hosting of SQL server.

Ledge: Obviously, that’s an interesting place that people can pay attention to. If you’re kind of trying to push the container bleeding edge, then watch out for those pit holes.

Dan: That’s one of the best advices I always give other developers and leads. Bleeding edge is nice. Everybody wants to use bleeding edge. Right now, it’s blockchain and serverless and AI. Those are your three hot terms, right?

Look them up and every conference is going to talk about those three.

The question you should always be asking is “Do you need it?”

If you’re trying to run a database like SQL Server, do you really need it to run the hottest, latest technology?

“We’ll try to run it serverless, a serverless database.”

Yes, I know that somebody is going to come on your podcast and they’ve done a serverless database.

But do you need it?

No.

Is there a tried-and-true way of getting that piece working?

If that’s going to be the core of your application ─ and I would argue that databases tend to be data that’s sort of really important ─ you should probably make sure you’re using the right tool that is known versus bleeding edge.

On the other hand, yes, if you have a need for optimization or some need for edge computing or whatever, use that. But temper that with using the right tools, the try-and-tested tools, the things that have already been tested and we know how they work.

Ledge: What’s the process you take somebody through to make that determination? You have a million choices now for tools. I mean, the tooling ecosystem is outrageous now. It’s huge. What is the process to take in organization or a client or your own company through to just get ‘What do I need here?’”

Dan: That’s an interesting question. The bad answer is “It depends.” But it does. I’m going to give you sort of my experience and what I tell the developers. Your first step should be to really understand the problem.

Before you try to bring in tooling, understand what your pain points are. Rather than going for best case, look for what your worst-case situation is going to be.

Is latency going to be a problem? Are you looking for giant data sets or small data sets? Are you looking for relations at all in your database?

When NoSQL came out, everybody wanted to go to NoSQL. Then, how do I relate the data?

That’s the whole point of NoSQL. It was not relational.

We had to back up a little bit.

So you have to look at your problem set. From there, you go to tooling. And then, for DevOps, you have that argument between Salt and Ansible and Chef.

I would say two things: One, I look at what closest to what your team familiar with. If everybody is a Python developer, you probably want to look at solutions that look closer to Python or work well with Python.

The Python community has adopted and has tooled. If you try to use some really cool brand new thing that doesn’t support on your technology stack, that is a wrong move.

So you want to use the right thing.

If you’re a new team or you’re hiring a new team, look at your community. Are you going to actually hire somebody ─

I’ve had conversations where somebody said, “You know, why don’t you code everything in AR?”

Great! Can I hire anybody who develops in AR?

It’s a pretty good challenge. There not a lot of AR developers out there.

Ledge: You can for $250 an hour.

Dan: But it’s going to be a lot easier for me to hire a bunch of Python devs because Python is more popular. But Python is single threaded and maybe it’s the wrong solution. So look at what you need, look at the resources you have available, and then pick the right solution.

I would also say that what always comes to my mind especially when in open source is what’s the community like? How many contributors? How often is it updated? What are people saying?

Read the forums. Certainly, there’s always somebody who hates it. There’s always somebody who loves it. What’s the middle ground saying? What’s their turnaround time on these things?

And get with your community. If you’re not going to meetups in your community ─ I’m sure some of your listeners may not be in an area where they can get to meet up; they’re in the suburbs somewhere. But if you can get to meet up, I think there are virtual meetups for a lot of these groups now, too.

Get working with communities and find out what people are saying. You’ll find a lot of feedback. After the initial excitement of a brand new product, you’ll get a lot of feedback about what people are actually using.

And that’s what really counts, right? If nobody is using it, it can be the coolest product in the world. If everybody is using it and there are a lot of community there, you’re going to find yourself with a lot more support.

Ledge: Absolutely! I think that’s right. So we’ve talked about the tooling layers and the selections and processes. Since being a software engineer twenty years and moving into the leadership position of it, I’d like to know ─ you know, we’re in the business of very senior remote software engineers.

From your perspective, if you were looking for the most excellent of senior engineers that you were to consume remotely because you just can’t simply find them locally or you want to expand the application of your team, what does that person look like? What are the key traits? What is the picture of that ideal super senior unicorn engineer?

Dan: Oh, man! I’m looking for a unicorn now?

Ledge: Purple unicorn, right?

Dan: I’ll tell you that what I look for primarily, again, is that community. I tend to look for developers, local or otherwise, if I can, who are in a community.

I have a guy who works for me right now. He’s a member of the Python community here in Chicago. He’s spoken at their conferences. I find that to be a good sign ─ that he knows his stuff.

Nobody is going to let somebody who doesn’t know anything talk or, at least, talk more than once.

So I look to that as a big thing. I tend to encourage my teams, remote or otherwise, to get out to those kinds of meetups. That means, they have to take some time off to do it.

I do look for the community and what people are saying about that person. The other thing is going to be “fit.”

I have an amazing guy who is a UX designer, Dave Harper. He works for me and he impressed me. The first thing he did in our interview is say, “We’re going to do on Skype.”

And he plugs me in and it was amazing. You could see his face. He was right there present. He was able to switch cameras so he was able to do basically everything you can do in person.

It made me feel the interview and has since made me feel like he might as well be in the room with me.

So when it comes to remote developers, that’s Key #1. You’ve got to be able to join a conversation and I’m not going to feel like you’re out of touch because you’re in a different location.

So it’s sort of that twofold thing: expertise and ability to communicate remotely in such a way that it doesn’t feel like you’re remote at all.

Ledge: Fantastic feedback! I think that’s really important. I think we talk about soft skills and it’s also about the delivery systems for those soft skills. If you don’t set yourself out in a way that you have a great connection ─ the cameras, the sound, and all those things ─ you just don’t get a chance to demonstrate your technical expertise.

It’s not enough to have skills at this point.

Dan: I would also say, getting back to some of our conversations earlier, when you have remote developers ─ and I do; I actually have two folks in England and I have a guy in Austin ─ having your DevOps pipeline is huge. If you’ve got them pushing code and we need my tester to view it and all these moving parts, if you don’t have a good GIT strategy and you don’t have a good DevOps strategy, you can forget about seeing your code and seeing what’s happening because the best developer in the world can never actually use the code that’s useless.

So we’ve had a huge amount of success by ─ our pipeline, you check it in; it goes straight to a dev instance within, I think, two minutes. And so, we’re seeing the results and we’re testing right away. That goes a long way.

Ledge: Fantastic advice! Dan, I appreciate that. It’s awesome having you on. Any additional last thoughts before we push publish?

Dan: No. This has been great. Thanks a lot.

Ledge: Absolutely good to have you on! I appreciate it.

Dan: Great!