Should You Break Up With Your Monolith?

© 2019 Perforce Software, Inc.
Should You Break Up Your Monolith?
TOM TYLER AND CHUCK GEHMAN | NOVEMBER 2019

perforce.com2 | © 2019 Perforce Software, Inc.
Speakers
Chuck Gehman
Technical Marketing Engineer, Perforce Software
Chuck is a Technical Marketing Engineer at Perforce. He has
worked as a CTO, architect, developer, and product leader
in startups and large enterprises. When he has spare time,
he enjoys volunteering for technology education initiatives,
attending Meetups, and writing.
Tom Tyler
Senior Consultant, Perforce Software
After starting his career at the NASA Kennedy Space Center,
Tom has consulted as a software developer and development
environment architect in many software development
organizations. Tom is passionate about training, mentoring,
and consulting with Perforce customers large and small.

Should You Break Up Your Monolith?
1
2
3
4
Why Break Up the Monolith?
Constructing the Right Approach
Implementing New Tools
Solving for the Legacy

• Need to:
• Modernize technology.
• Deliver value to customers more quickly.
• Address pain points:
• System is too difficult to maintain.
• Inability to identify issues quickly.
• Long delays in handoffs between dev, QA, and
operations.
• Too many defects released to production.
• Cannot find developers to work on fragile, legacy
code base.
• Stifling innovation.
Why Break Up the Monolith?

• Monolith is probably generating enormous
amounts of revenue for the company.
• But customers want more, new features.
• Rising fear of disruptive competitors.
• Business risks in upgrading your monolith:
• Delays to development.
• Concerns with new architecture working.
• Stability/reliability.
• Refactoring is a multi-year project.
Risks and Pain Points

Constructing The Right Approach

• Steps for a less painful migration:
• Assess low-hanging fruit.
• Break-off and refactor after you migrate.
• Attack a component/package/service in a logical order.
• Adopt new tools throughout the process.
• Goal = Support both the old and the new models
simultaneously.
Constructing a New Environment

1. Start with capabilities of the monolith that are decoupled and don’t require changes to customer-facing apps.
2. Focus on delivery approaches, upskilling team members.
3. Build out minimum infrastructure needed to deliver independently deployable components (e.g., containerized
microservices) that expose self-service APIs.
4. Start tracking technical issues for new and legacy:
• Counting errors released to production
• Service availability
• Time to remediate, etc.
5. Consider cloud deployment options (as appropriate).
6. Implement basic monitoring for new and legacy.
7. Implement automation wherever possible.
8. Migrate in atomic steps.
Step-By-Step Approach

• Review existing tools and process.
• Look at direct costs of licenses, maintenance, and hardware as well as personnel time that can be recovered.
• What challenges do your teams face?
• Speed?
• Scale?
• Supporting multiple facilities?
• Integration with popular DevOps tools?
• Legacy hardware?
• Build out the underlying infrastructure to support modern architecture:
• Version control.
• CI/CD pipelines.
• API management.
Review the Current State and Goals

• Issues with keeping old legacy tooling around forever:
• Keep paying license costs.
• Run the risk of admin retiring, and difficulty hiring new admins.
• Performance and automation disadvantages.
• Some may want to try to move the legacy codebase to Git.
• Git lacks the ability to support dimensions of scale:
• Number of people.
• Number of projects.
• Size of files.
• Size of repositories.
• Number of geographic locations.
Review Your Choices

• Is Git great for microservices?
• Yes, it is used by many companies today.
• Is Git a great place to migrate the monolith codebase and legacy production workflow?
• Not so much.
• To move into Git, you would have to do years’ worth of work FIRST,
and then try to migrate.
• You don’t have time to wait.
Is Git the Best Option?

• You can develop for the future and maintain the legacy with the right VCS –– Helix Core.
• Helix Core serves the needs of the old and new code base, in a unified system.
• Helix Core can handle the entire monolith “as-is” without requiring major refactoring first.
• Just import and GO! No barriers, no risk.
• No immediate need to break up your monolith.
• Once in Helix Core, you can methodically attack a component/package/service one at a time.
• The tooling/process should support your transition seamlessly.
• If you are trying to migrate some of these components/packages to a Git based solution:
• Do this seamlessly using Helix4Git without impacting the build & release process.
• Flexibility to manage the carved out components in Helix Core, or any Git management tool.
The Right VCS
HELIX CORE

• High-level migration strategies –– how much history do you
need?
• Tips.
• Detailed History Import (DHI).
• Baseline and Branch Import (BBI).
• ClearCase to Perforce Migration.
• SVN to Perforce Migration.
• Steps for Your Complex Project.
What Should You do With Legacy Code?

• Tips Only:
• Copy tips into new system.
• Baseline & Branch Import (BBI):
• Bring along only “interesting” history.
• Baselines and high-level branch operations.
• Detailed History Import (DHI)
• Bring historical details into Helix Core.
How Much History Do You Need?

How Much History Do You Need?
• Detailed History Import (DHI): • Baseline and Branch Import:

• VOBs and Depots.
• ClearCase MultiSite/Regions.
• VOBs Servers vs. “The Server (Super VOB).”
• Registry and license servers.
• Not necessary in Perforce.
• Rethinking label strategies.
• Take advantage of lightweight, automatic labels in Helix Core.
• Leverage the power of the changelist!
• Unified Change Management (UCM) vs. Perforce Streams:
• Helix Core gives you branching and merging with guardrails that you define.
• Technical Challenges:
• For example, “Evil Twins.”
ClearCase to Perforce Migration

• Options are similar to ClearCase migrations.
• Benefits of Migrating:
• Major performance enhancements.
• Replication around the globe.
• Conflict-free merges (saves time and money).
• Enables parallel development at scale.
• Makes your entire team more productive.
• Migration Challenges:
• Big repos take resources to move over (especially with DHI imports).
• Fully supported tools available to help migrate.
SVN to Perforce Migration

• Step 1: Choose a new version control system that
provides the foundation for both legacy systems and
forward-looking development.
• Step 2: Methodically plan and choose the parts of
the monolith that can transition to a more modern
architecture and have the best impact on the
business.
• Step 3: Along the way, use integration with best of
class tools (existing and new) for both legacy and
new.
• Automate your enterprise SDLC.
• Reduce risk and optimize productivity.
• Achieve lower tooling costs along the way!
Conclusion: Simple Steps For Your Complex Project

Should You Break Up With Your Monolith?

Recommended

More Related Content

What's hot (20)

Similar to Should You Break Up With Your Monolith? (20)

More from Perforce (20)

Recently uploaded (20)

Should You Break Up With Your Monolith?