Do you have a monolith? If so, is it majestic? Or is it broken and preventing you from scaling your application and your business? Monoliths have earned a bad reputation in software architecture design circles for being difficult to maintain and operating on silos of knowledge. However, they aren't all bad. The key is knowing when to use a monolith, and when it is time re-factor and scale up by going small.

1. Beware the
Monolith
Presentation by Dee Wilcox
Nashville PHP - March 8, 2016

2. Developing for Scale
In enterprise-level development projects, or
projects where the application is the business, it is
easy to find ourselves unintentionally scaling up to
a monolith. This month we’ll spend some time
learning together how we can build stable
enterprise applications that scale, while moving
away from this architectural design pattern.

3. Speak up! Take the survey.
(With a little help from your smart phone)
http://goo.gl/forms/o3qJZ1Krpw
Are you working on a
monolith or distributed
system?
Which do you prefer?

4. Source: xkcd.com/1504/

5. 1. What is a Monolith?
How do you know if you are working on one?
➔ Single-Tiered
The user interface and data access
code are combined into a single
program from a single platform. Very
few layers of abstraction.
➔ Self-Contained
Independent from other systems and
applications.
➔ Deeply Integrated
Models are collapsed for simplicity.

6. It’s an integrated system that
collapses as many unnecessary
conceptual models as possible.
Eliminates as much needless
abstraction as you can swing a
hammer at. IT’S A BIG FAT NO
TO DISTRIBUTING YOUR
SYSTEM lest it truly prevents
you from doing what really
needs to be done.
Source
From Majestic
Monolith by David
Heinemeier Hansson
on SignalVsNoise

7. 2. Benefits of a
Monolith
➔ One codebase to
maintain
➔ Application logic is
tightly coupled to the
data model and user
interface
➔ Everything is in one place

8. Monoliths aren’t all bad. In fact, they are widely
used even in modern tech companies. But when
polled, most Nashville-based developers preferred
a distributed architecture. We can
debate which way is right, but it really
depends on the application and the
environment.

9. Meet Etsy.
Either Etsy is a monolith or it is a
shining example of what service-
oriented architecture looks like
and/or microservices, depending on
who you ask...
There are other languages at play at
Etsy, but as far as the guts of the API
and the web application, it is largely
PHP. There’s a huge advantage in
that, a massive advantage.
Source
Microservices,
monoliths and laser
nail guns: Etsy tech
boss on finding the
right focus

10. Meet Bootcamp.
One of the benefits to the
majestic monolith is that it
basically presumes that
the people who work on it
also understand it.
Source
The Majestic Monolith

11. Monoliths work best
on small teams
dedicated to one
application. Even in the best case
scenario,
documentation,
documentation! Silos of
knowledge are
dangerous without
documentation..

12. Now for some data.
(Thanks to everyone for participating!)
This survey was limited to the
NashDev Slack team and the
Nashville PHP meetup group.
http://goo.
gl/forms/o3qJZ1Krp
w

13. Meet Netflix.
“Give the developers the
pain, and they'll automate
everything out of the way.”
Source
https://www.battery.
com/our-
team/member/adrian-
cockcroft/

14. Defeat the monolith by
going small. Tiny, even.
Microservices are small applications that
represent one piece of business logic, or one
function within the application. When designed
as an API, the application becomes a front end
client consuming various API endpoints.
Pro Tip
Microservices can be
broken down into larger
chunks, but generally,
the smaller, the better.
This makes them easier
to maintain and helps
keep the system
decoupled.

15. 3. Benefits of
Microservices
➔ Application logic, user interface,
and data models are de-
coupled.
➔ Easier to maintain and deploy.
➔ Easier to teach to new team
members.
➔ Increases application stability.
➔ Ability to fail gracefully.

16. Strong
application
architecture is a
simple as clear
lines and simple
patterns.

17. Consider the simple marble run.
COMPLEX PATTERNS
COMBINED WITH MILLIONS
OF DESIGN CHOICES
SLOW DOWN THE
SYSTEMAND MAKE IT
DIFFICULT TO UNDERSTAND.
Source: thisiscolossal.com

18. Some of our
monolithic
applications end
up looking like
this.

19. But perhaps they should
look more like this.

20. Building API Centric
Applications
An API Centric web application executes most, if
not all, of its functionality through API calls. The
application is separated into the front end client
and the codebase(s) for the API(s) it consumes. A
formerly monolithic app will likely consume many
microservices.

21. 4. Best Practices
➔ Design your application so that it
is consuming APIs from your
microservices.
➔ Break each business task out into
a microservice with an exposed API.
➔ Require authentication with your
services. It goes without saying, but
this is an crucial for security.
➔ Use AWS to distribute and load
balance your services. We have
seen huge performance gains simply by
moving our infrastructure to AWS.

22. tl;dr
Microservices,
Monoliths, and
Laser Nail
Guns
Adopting
Microservices at
Netflix: Lessons
for Team and
Process Design
Microservices:
A Definition of
This New
Architectural
Term

23. Stay in Touch
t/s/l
@dee_wilcox
e/
dee.wilcox@mac.com