Like a lot of online businesses today, PrepSportswear’s success is 100% dependent on the availability, scalability and performance of their digital online services. If the website is down, the business stops. They knew they had to transform their business from that of a retailer with a website to a high caliber IT company that sells products online. In these webinar slides, Richard Dominguez, PrepSportswear’s Developer in Operations, shares their journey. They transformed from a team operating a monolithic app using waterfall development methodology on an old, hard to maintain code base, to a modern IT organization applying new practices from Agile development, DevOps and a Service-Oriented Architectural approach. The Impact? PrepSportswear’s Most Successful Online Holiday Shopping Season in Company History! Join us to: Learn how to identify if you are running a monolithic application that is dragging you down. Get tips on hiring the right people to inject a DevOps cultural mindset into your organization. Understand how to break the monolith into smaller pieces that support key lines of business. Discover where to automate monitoring into your pipeline and platform. Identify metrics for individual stakeholders (dev vs. test vs. business). Go forward, celebrate, learn from, and repeat success! Richard will be joined by Andreas Grabner, Performance Advocate at Dynatrace who will support why monitoring, application and end user metrics have to be a key part of your own transformation! Richard Dominguez has 9+ years’ experience as both a System Analyst and Software Developer in Test. He has worked on many high profile projects in Microsoft such as Hyper-V, Windows 7 Client Performance, and Windows Phone Services. Richard now works at PrepSportswear as the company’s DevOps engineer. His responsibilities include site reliability, external synthetic testing, release management and overall site performance. Andreas Grabner has 15+ years’ experience as an architect and developer in the Java and .NET space. In his current role, Andi works as an advocate for high performing applications in both the development and operations areas. He is a regular expert and contributor to large performance communities, a frequent speaker at technology conferences and regularly publishes articles blogs on blog.dynatrace.com

1. 6 ways DevOps helped
PrepSportswear move from
monolith to microservices
Andi Grabner
Performance Advocate
@grabnerandi
Richard Dominguez
Developer in Operations
Prep Sportswear

2. The Promise of

5. Confidential, Dynatrace, LLC
Goal: Becoming a software defined business
$108m
$400m
$2bn est.
2013 2014 2015
Source: “Creative destruction in the S&P500 index,” Jan 2014; "Uber Expands Funding Round as Revenue Growth Acceleratesm," Wall Street Journal,
Feb 2015. See more discussion in “The Three Horsemen of the Digital Apocalypse Considered.”
52% of G500 since 2000 GONE Uber rumored net revenue

6. What they
really want!

8. 700 deployments / YEAR
10 + deployments / DAY
50 – 60 deployments / DAY
Every 11.6 SECONDS

9. Not only fast delivered but also delivering fast!
-1000ms +2%
Response Time Conversions
-1000ms +10%
+100ms -1%

10. Rate performance/response time as the #1
mobile app expectation
- ahead of features and functionality -
Source: Forrester Research 2014

11. Why most
(will) fail!

13. Agenda and learning journey
2005
CEO started
with new
business idea
Most successful
shopping season in
company history
Building a
DevOps Culture
Building a website
Growing the
monolith
Increased
deployments
resulted in more
failed deployments
Our pipeline: why
we deploy less
frequently today!
Breaking the
monolith -
deploy more
frequent
Started with
monitoring
Response time and
availabilty
improvements
. . . 2014 2015 20172016

14. Let’s begin! PrepSportswear 10 years ago . . .
• SportsWear Inc. started out with our
CEO Chad Hardvigson personally
pressing shirts
• The demand for specially made sport
attire was high
• No one was providing this type of
specialty service

15. Technology ramp-up to the rescue . . .
• We needed a website
• Automation was needed to handle
large demand
• New techniques in printing
automation was quickly developed
to meet increasing demand

16. Rapid development put stability in the back seat
• Fast development lead to
continual instability
• Instability lead to consistent
breaks
• Consistent breaks lead to
developer ‘blindness’

17. Large buildup of half-done projects
• Development team was
isolated from the rest of the
company
• Requirements for projects
were deemed by the
development team only
• No true concept of “done” –
no monitoring of usage

18. Monolith started to take shape
• Its easier to develop new
features on top of each other
• Its easier to setup one single
(though large) application
• Testing individual components,
however became very difficult

19. You are not alone in this world!

20. The Monolith was getting uncontrollable
• PrepSportswear was heading
toward a development nightmare
• Development team didn’t want to
‘see’ this reality
• Constant fixes were a common
occurrence
HOW MANY DEPLOYMENTS
DID YOU MAKE?

21. It‘s not about blind automation of pushing more
bad code on new stacks through a pipeline

22. It‘s not about blindly giving everyone ops power
to deploy changes only tested locally

23. Hard decisions needed to be made . . .
• New Director of Information
Technology was hired to
“help” with the system
• Old development team didn’t
see a problem – this caused a
lot of friction
• Certain individuals were let go

24. PrepSportswear’s new beginning
• Hired the “right” people
• DevOps mentality was soon adopted.
• Moved into a two week sprint process
• Reduced the number of deployments

25. We needed to reduce the number of deployments
• Increased the Quality for each
deployment
• Needed to create proper
Monitoring when Deployment
occurred
• Invested in External
Monitoring

26. Performance increase when new team started
Keynote time graph (April2014 – Dec 2015)

27. Performance increase when new team started
Time chart showing uptime availability (April2014 – Dec 2015)

28. Monitoring, monitoring, monitoring
• Adopted a true APM system
• Implemented proper hardware
monitoring
• No more “customer’s will let us
know if we have issues”…

29. Cool dashboards & metrics for biz & dev

30. Dashboards & metrics for DevOps
performance focused

31. Dashboard & metrics for marketing

32. • Overloaded Pages
• Memory Leaks
• Too many Database Queries
• Bad External Web Service Calls
• Threading Issues
• Caching Issues
• SEO Overuse of bots causing larger
load then nessessary
• ....
Some of the top problems found ...

33. #1: Dev: Don’t Check In Bad Code
Step #1: Execute
your Tests just as you
always do ...
Step #2: ... but DO IT
WITH Dynatrace!!

34. #1: Dev: Don’t Check In Bad Code
Step #1: Execute
your Tests just as you
always do ...
Step #2: ... but DO IT
WITH Dynatrace!!
Step #3: Verify Code works as
intended without leaving the IDE!

35. #1: Analyzing every Unit,
Integration & REST API test
#2: Key Architectural
Metrics for each test
#3: Detecting regression based
on measure per Checkin
#2: CI/CD: Stop Bad Builds through Metrics

36. #3: Ops: Monitor your Services/Users after Deploy
#1: Usage
Tip: UEM Conversion!
#2: Load vs Response
Tip: See unusual spikes
#3: Architectural Metrics
DB, Exceptions, Web
Service Calls

37. #1: Do my campaigns work?
#2: Who are my users?
#5: Biz: Understand your End Users

38. #6: Biz/UX: Optimize End User Behavior
#1: Are they using the
features we built?
#2: Is there a difference
between Premium and
Normal users?
#3: Does Performance have
a Behavior Impact?

39. Metrics-Driven Pipeline: Stop Bad Builds Early!
Dev&Test: Personal License
to Stop Bad Code when it
gets created!
Tip: Dont leave your IDE!
Continuous Integration: Auto-Stop Bad Builds based on
AppMetrics from Unit-, Integration, - Perf Tests
Tip: integrate with Jenkins, Bamboo ...
Prod: Monitor Usage and Runtime
Behavior per Service, User Action,
Feature ...
Tip: Stream to ELK, Splunk and Co ...
Automated Tests: Identify Non-Functional
Problems by looking at App Metrics
Tip: Feed data back into your test tool!

40. PrepSportswear build pipeline
• Developer checks in code
• We use release branching on Git
• We run a Release Build from TeamCity
• Build Code, Verify Build, Deploy in Test Environment
• Run Functional Tests & Manual Acceptance Tests
• We dogfood our code: Deploy internally and use the new code
• Since it’s a monolith app, everything is in the same deployment (e-commerce site, internal
only back-end services, marketing diagnostics, designer tools, etc..)
• Watch Dynatrace for failed transactions, poor performance, etc

41. PrepSportswear Build Pipeline (continued)
• Pre-Release TiP – Test in Production
• Deploy new code to a small set of servers that
will serve <10% traffic
• Deployed servers have a higher set of Dynatrace
sensors that will be used to highly monitor
incoming traffic.
• Once satisfied, we release to the rest of our
external servers on the official release date

42. The way forward… micro services
• Why move to Micro Services?
• What Micro Services mean to
maintain Business Relevance
• Does the Cost justify the
means to move toward Micro
Services?

43. Image server as part of the monolith app

44. Future: Continuing breaking up the monolith
• Identifying Key Lines of Business of your App
• Figuring out what is internal only and
external only
• Dependency Management

45. Q & A
Andi Grabner
Performance Advocate
@grabnerandi
Richard Dominguez
Developer in Operations
Prep Sportswear

46. Performance management for the digital customer age