1 of 12

Slide Notes

Intro:
- Quinn Murphy, Sr Systems Engineer for Centralized Services at Netsuite

- What this means is I work to standardize and mature many of our brands that we acquired

- Until recently, I was Team Lead **for** one of those brands -- Openair.

- This talk is about using containers to put that product on the road to more dynamic infrastructure.

- many people wonder where to start, how to go from here to there. This is how we started.
- we are not totlly into microservices yet, but we are almost at the cusp in a way that we were not before.
DownloadGo Live

Monoliths & Microservices: A Journey

Published on May 24, 2016

No Description

View Outline

MORE DECKS TO EXPLORE

To Be Curious

25884 views

7 Strategies to Write a Speech with Ease

84698 views

10 ways

45208 views

TXLA Wrap-up 2015

9451 views

What is Creativity

67884 views

What is Media Literacy Today?

25818 views

PRESENTATION OUTLINE

1.

Monoliths & Microservices

A Journey
Intro:
- Quinn Murphy, Sr Systems Engineer for Centralized Services at Netsuite

- What this means is I work to standardize and mature many of our brands that we acquired

- Until recently, I was Team Lead **for** one of those brands -- Openair.

- This talk is about using containers to put that product on the road to more dynamic infrastructure.

- many people wonder where to start, how to go from here to there. This is how we started.
- we are not totlly into microservices yet, but we are almost at the cusp in a way that we were not before.
Photo by johnarobb
2.

Living with the Legacy

- We had a LAMP (P for perl) application many years old, with no dedicated ops team when I came in.
- Spent many years cleaning that up, and wanted to evolve...
- but there was no dev environment that resembled production
- painfully slow, compile all code deploy could take 2-4 hours
- no way to innovate/re-design that we could trust
- if only we had an opportunity...
Photo by ajmexico
3.

A Wild Opportunity Appears!

- and a wild opportunity does appear!

- change was coming slowly, though it was clear what needed to happen. We needed a way to test infraastructure changes

- we were slated to introduce a release preview site for customers, so for 2 weeks they could see the new code.

- the problems though...
Photo by crdotx
4.

Sorry about those Resources

Not a lot of money or time.
- unfortunately, not a lot of resources for us to use.

- while performance wasn't on the docket, always nice.

- how to maximize the limited hardware we had without creating more monolith bloat?

- what to use?
5.

It's Super effective!

Dockerchu FTW
- We used Docker very early in it's life-cycle.

- It would help us utilize our resources more efficiently

- combine with a NetApp snapmirror for data mobility.

(image used from seankenney.com)
6.

Encapsulating Pain

Feel Install Pain Once, Then Never.
- containerize the web and data servers

- It was a painful install, as the app was set up for a very specific environment that wasn't documented that well.

- a nice side-benefit is that going through this pain once actually encapsulated it.
7.

Big Wins

  • 2 hour installations became a few seconds.
  • Faster Site Deployment
  • Good Performance for Cost
- 2 hour installations became a few seconds.
- releasing the first version of the site was a big win
- deploy reasonably performant machine-for-machine copy of the site
- spun up in about twenty minutes.
8.

Orchestration 0.OMG

Painless vs. Less Painful
- but this was back before the days of enterprise orchestration

- cobbled together placement of containers using KVM,
spreadsheets, and Rundeck

- just **less** painful
Photo by Alvaro A. Novo
9.

Levelling Up

- We wanted a platform that could be replicated by dev and QA

- but we needed something composable, scalable, observable.

- Something easy to replicate to different contexts.
Photo by artnoose
10.

Moving Forward.

- today we've upgraded the containers to a stack of Openstack/CoreOS/Kubernetes

- we can spin up the entire site in 1 minute by running a simple up script

- we now have something that dev and QA can consume.

- we now have the platform to which we can break down the service.
11.

Lessons Learned

  • Encapsulation is a big win you can get early
  • Working on the ground underneath your app prepares you to break down the monolith
- wrapping up:
- just the act of containerizing your legacy app is useful.
- encapsulating the app can alleviate some pains immediately
- prepares you to change the underlying infrastructure
- ...which prepares you to break up into smaller services later.
12.

Thank You!

Photo by owly9

Quinn Murphy