When To Be Monolithic and When Not To Be , with Phil Borlin
To be or not to be monolithic, that is the question. Here with the answer is Phil Borlin of PluralSight and Veyo. Phil and I met a few years ago when he moved to San Diego to work with PluralSight.
On this episode we discuss when to break up a monolithic app, why you should start that way but not stay and when self-contained systems are a good solution. Join us to hear the details on those topics and more on today’s edition of CTO Studio.
In this episode you’ll hear:
- How does he define self-contained systems?
- When should you break up a monolithic app?
- Why you should have your front end and back end developer on the same team.
- Are they doing mob programming? Why or why not?
- What does a healthy exec team provide, according to Phil?
- And so much more!
Although he grew up in southern California, Phil went to Salt Lake City for his undergraduate degree and then to Colorado State for his master’s. Both degrees were in computer science, with his master’s focused on software engineering.
After talking about his background briefly, we get into the monolithic discussion. Phil says we should be doing things two or three times before breaking things out because we don’t understand where our abstractions should be until we do that. So if we are starting out start as a monolith, the reason to break out is to lower communication costs between teams.
The time to do this is when you’ve grown to your 10th or 12th developer and can split up into three teams, then you should start thinking about this. And the reason is because it’s more about team efficiency rather than scale.
We also talk about self-contained systems as a subset of service-oriented architecture. Phil advocates keeping your front end and your back end and your databases close to each other, giving teams their own code bases and their own databases and then using some kind of data replication or some kind of calling into other people’s APIs in order to cross those boundaries. By doing so you can have small communication boundaries between other teams and lots of room to innovate on your own team.
I was curious to know more about what Veyo does exactly. Phil explains that
Medicare and Medicaid programs are two fantastic programs that give certain groups of people access to healthcare, people who may not normally be able to afford it.
These groups of people often struggle with getting to their appointments, they may no longer drive or they may not have someone who can take them. This is where Veyo steps in and provides transportation for those people to their medical appointments at no cost to them, Medicare and Medicaid pays the fees for these people.
While it might sound like a gig economy type of service, Phil says it’s a more holistic approach than lyft or uber. People can use public transportation and be reimbursed for it, for example. In Connecticut Veyo mails out the bus token to the person and the person then uses it to get on the bus and go to their appointment.
The point is to not have these people pay for their transportation by pooling federal and state funds to cover the fees. Of course these are non-emergency medical transportation needs only, typically for appointments like follow-ups, dialysis, etc.
Next we get into the actual app experience and more of the “geeky” details. Phil has been the Director of Engineering for about 5 months or so. it was a dot net shop when he got there, much of the code stil is today.
Also on today’s show we talk about which aspects of the Veyo app he has identified as monolithic and what he’s done as a result, Kubernetes, Azure and Google cloud, and why you would do containers or not depending on the situation. Lastly he shares what tech is most exciting for him now – TLA Plus. Join us to hear more about what that is exactly on today’s edition of CTO Studio.
Episode Resources:
Share This Story, Choose Your Platform!
Related Podcasts
