Adopting a Scalable Technology Stack to Satisfy the Demands of Telecom's Rapid Quoting Growth

MS

From Monolith toServerless:

Table of ContentsIntro

Growth & Obstacles

Welcome Home

Monoliths & Microservices

Serverless

Phase 1 - Lift & Shift

Phase 2 - The Rebuild

Phase 2 - Traditional Cloud vs. Serverless

Phase 2 - Tooling

Retrospection

3

4

5

6

9

11

13

14

15

17

Intro

Who we are

Technology is pervasive, touching almost every

aspect of our daily lives. Businesses strive to stay

relevant in an ever-changing technical landscape.

With technological advancements occurring every

day, being conscious of and adopting new

technology trends, is vital to retain a competitive

edge.

Over a decade ago, MasterStream revolutionized

telecom quoting with the launch of a unique

CPQ software allows sales organizations to configure complex product quotes, with the ability to generate proposal documents, using specialized markup or discount pricing logic.

3

When faced with obstacles that would attempt to inhibit our growth, MasterStream remained steadfast to these

principles; inspiring us to reevaluate our long-term technology strategy. Taking advantage of an opportunity to

overcome several software development challenges, meant rethinking traditional methodologies and

conventional designs.

Configure PriceQuote (CQP)

Automation Quality Accuracy

Configure Price Quote (CPQ) solution. Leveraging in-depth industry knowledge and expertise, MasterStream

delivers complex quoting solutions, focusing on automation, quality, and accuracy.

Growth & Obstacles

Interconnectedness

Resembling many similar SaaS growth stories, MasterStream was presented with a seemingly impossible

scalability problem. For the first time in our company's history, our rapid CPQ quoting growth was limited by

fundamental drawbacks, predominantly related to our on-premise (on-prem) server architecture.

As our network of interconnected telecom agents, providers, and carriers expanded, CPQ quoting volumes

outpaced our on-prem server capacity. The ability to quickly provision new server capacity was bridled by long

setup times and extensive server infrastructure and DevOps costs. As time was of the essence, the need for

automated, server scalability became paramount.

Auto-scaling automatically increases or decreases

the number of allocated servers to an application,

based on its throughput needs at any given time.

This type of system doesn't need continual

reconfiguration to produce consistent performance

when put under heavy traffic. If executed correctly,

this type of auto-scaled architecture would

dramatically increase reliability and performance.

When migrating legacy systems to an auto-scaled,

cloud architecture, many hidden complexities and

hurdles may present themselves throughout that

process. With the promise of lower DevOps costs,

consistent user experience, and greater agility on

the horizon, our engineering team prepared

themselves to tackle these obstacles head-on.

4

Welcome Home

Phase 1 - To the Cloud

Scalability would not be easily accomplished

with a simple move to an auto-scaled cloud

architecture. It would be much more

problematic, requiring a multi-phase plan of

attack. Choosing the right cloud provider,

recruiting a strong DevOps team and

meticulously crafting pre-launch, launch and

rollback documentation are just a few of the

5

Lift and Shift is one method to migrate an entire software application platform to the cloud without the need for a complete redesign.

Lift and Shift

Phase one of this procedure would involve a "lift and shift" migration strategy, relocating our servers to

an AWS' Elastic Compute Cloud (EC2) platform. A lift and shift strategy would immediately afford us

much-needed scalability, without the need for a full software application rewrite.

steps necessary for a migration of this magnitude.

Monoliths & Microservices

Phase 2 - Addressing the Monolith

Our newly implemented auto-scaled architecture

brought about substantial server infrastructure and

DevOps costs, as well as a higher degree of

complexity. With the introduction of these new

complications, phase two of our scalability plan

would require an entire rebuild of our monolithic

application. Software applications are defined as

"monolithic" when its functionally distinct aspects

6

A software application is defined as "monolithic" when it's functionally distinct aspects are all interwoven, rather than containing architecturally separate components.

Monolith

Microservices architecture is one way to accomplish the development of large or complex business solutions.

Microservices enlist smaller sets of code, working together to achieve a single purposed task. These

collections of individual, specialized services are optimized to carry out specific business functionalities.

A traditional microservices design pattern,

provisioned on a typical AWS EC2 scaled

environment, was our first attempt at this massive

rebuild. Provisioning and managing this new

microservices server infrastructure was costly and

would impede our ability to develop software

quickly.

Microservices architecture enlist smaller sets of code, working together to achieve a single purposed task.

Microservices

are all interwoven, rather than containing architecturally separate components.

Monolith

7

Exhibit A: In this digram of a basic Monolithic Architecture, all of the functionally distinct aspects are housed in one application.

Microservices

8

Exhibit B: In this diagram of a Microservices based architecture, the business logic layer consists of smaller functionalities that are distributed across the system, that work together to accomplish a proposed task. These smaller functions can scale independently of one another, in proportion to the amount of throughput that they receive.

Serverless

9

A Serverless architecture means that infrastructure management responsibilities such as provisioning servers, patching, operating system maintenance, and capacity management, handled by a third party, so that a development team can focus solely on coding functionality.

Servers? What Servers?

With Serverless, infrastructure management

responsibilities such as provisioning servers,

patching, operating system maintenance, and

capacity management, are no longer a concern.

Software applications can be built and deployed

to the cloud, eliminating the need to manage the

servers they run on. 

Eradicating DevOps responsibilities and reducing

infrastructure costs would require thinking

outside of the box, by capitalizing on "Serverless"

cloud solutions. Serverless mitigates the

management of server infrastructure, reduces

cost, and allows software engineers to focus on

software development entirely.

Serverless 

Serverless

10

Exhibit C: In this diagram of a Serverless model, Amazon Web Services is the third

party cloud provider that manages and provisions the infrastructure. These smaller

functions can scale independently of one another, in proportion to the amount of

throughput that they receive.

Phase 1 – Lift & Shift

Growing Pains

Admittedly, in early 2018, the excitement generated

from the completion of our lift and shift plan was short-

lived. Unforeseen application, database, and networking

misconfigurations produced numerous software bugs

and system outages. Grounded by these issues, we

worked to resolve each one quickly, eventually bringing

stability to our system.

11

Custom server configuration artifacts, essential for the successful operation of our application, remained buried

within a 15-year-old, legacy server environment. Only software bugs or system outages succeeded in exposing

these missing configuration requirements within our new system. This unearthing process would span the better

half of 2018 and consume hundreds of development hours, necessary to debug these issues.

Even though we experienced considerable

growing pains, many enhancements were

realized throughout this migration. At the heart

of our newly scalable platform, is an open-source

containerization management tool called

Kubernetes.  An alternative to full machine

virtualization is containerization, which involves

encapsulating an application inside a container

with its distinct operating environment.

Kubernetes Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management.

Phase 1 – Lift and Shift (cont.)

Container Orchestration

Kubernetes allows us to install an independent

instance of our software application, within a single

container, provisioned on an AWS EC2 resource. In

seconds, our software application can horizontally

scale, by increasing the number of application

containers necessary to match CPQ quoting workloads.

In this new cloud world, not only could we scale our

application servers but our database servers as well.

12

Forging Ahead

Although these examples are not exhaustive,

they exemplify the reasoning behind our lift

and shift cloud migration strategy. Thus, we

were able to focus on the next phase of our

scalability plan that would address our

astronomical server infrastructure and DevOps

costs.

With the adoption of Amazon's newly released Aurora relational database service, we immediately experienced

gains in performance, scalability, availability, and durability. Being that Aurora is a fully managed AWS service,

all database management responsibilities such as hardware provisioning, software patching, setups,

configuration, or backups were no longer required.

Consistent EnvironmentTime Savings

VisibilityIncreased Portability

Rolling Updates

Version Control

Increased E�ciency

Horizontal Scaling

Scaling

Automated Rollbacks

Canary Deployments

Phase 2 - The Rebuild

13

* from 2017 to 2019

275%Increase in CPQQuote Growth

* from 2017 to 2019

317%Increase in Server and

DevOps costs

With the migration to cloud now behind us, we were able to process more CPQ quotes than we could have ever imagined, but this enhancement came with a steep price tag. Horizontally scaling a monolithic application of this size became financially unsustainable.

As you can see in the example above, the increase in server infrastructure and DevOps costs was unprecedented, much higher than previously anticipated. Reducing these hefty costs, meant performing a complete system rebuild, leveraging a microservice design pattern. Now, instead of horizontally scaling the entire application, each microservice could be scaled independently of the whole application. Not only would this reduce these costs, but the business could immediately realize revenue for smaller, individual products brought to market, without waiting for an entire system rebuild.

Phase 2 - Traditional Cloud vs. ServerlessScalability Options

Seemingly, a traditional AWS EC2 architecture was

the correct path to host our microservices

application. It became evident that the time spent

provisioning and maintaining server infrastructure

would drastically outweigh the time spent

developing new software. Lengthy server

provisioning efforts protracted the release of or

first set of microservices. 

Seeking an alternative server scaling strategy was

essential to alleviate these costs, reduce

complexity, and shorten overall time to market.

14

“Anything that involves you

managing a host, patching a host, or

dealing with anything on an

operating system level, is not

something you have to do in the

serverless world.” 

- Chris Munns, Principal Developer Advocate - Serverless @ Amazon Web

Services, 2017

For us, AWS' Lambda Serverless platform would be that alternative. Struggling to crawl during its infancy, and

fast approaching its adolescence, Serverless introduces unique complexity to the software development

process. Each of these minor impediments would require additional problem solving and a well thought out

plan within a Serverless world.

Source Code Development

ConfigurationManagement

ContinuousIntegration (CI)

ContinuousDelivery (CD)

Monitoring Security

Phase 2 - Tooling

Build or Buy

The decision to build our own, or purchase an out-

of-the-box solution to address these areas of

concern, would require careful consideration.

Thankfully, Serverless pioneers like Stackery.io

and Epsagon have met these challenges head-on,

with exceptional software solutions.

Stackery is a unique start-up which helps

developers to create both cloud-side and local

Serverless development environments, bridging

the gap between cloud and local development —

at the same time, automating safeguards, best

practices, and curating CloudWatch metrics.

Provisioning and configuring cloud resources is

effortless, alleviating hours of AWS cloud

resource management.

15

Brighter Days Ahead

Before the use of Stackery's automation solution,

our engineer's would spend hours researching and

configuring infrastructure as code, to provision

AWS resources in the cloud.

Depending on the level of complexity, configuring

and provisioning an AWS CloudFormation stack,

with all of the resources necessary for its

successful operation, could take hours, if not

days. On the other hand, with Stackery's intuitive

user interface, provisioning a similar stack could

be reduced to minutes.

Phase 2 - Tooling (cont.)

Community

The future of cloud tooling is healthy

relationships and even stronger SaaS

integrations. Integrations between companies like

Stackery and Epsagon, bring significant value to

the Serverless community. Choosing the right

solution providers for our Serverless tool-set

would require vetting and much needed due

diligence in this ever-changing technology space.

The distributed nature of modern Serverless

applications makes troubleshooting and

monitoring a complicated task. Higher levels of

"Stackery and Epsagon can vastly

increase the observability of your

applications, making it much easier to

see how your apps are working (or

breaking) without having to examine

their internal code or add debugging."

16

Epsagon, a leader in the serverless observability space, provides visibility to obscured places within our system.

Their product is suitable for Serverless environments where traditional monitoring tools can no longer run, and

simple logs and metrics are not enough. The visibility gained from Epsagon, coupled with Stackery's infrastructure

automation, have been invaluable tools for our Serverless tool-set.

- Sam Goldstien, VP Product & Engineering @ Stackery, 2019

intricacy may result in additional cost. We effortlessly navigated these observability needs by implementing

Epsagon's blend of monitoring and troubleshooting solutions.

Stronger Together

The benefits gained from choosing a robust 3rd party provider tool-set would be crucial when laying the groundwork

for a stable Serverless environment. System stability preserves precious development time, dedicating our

development efforts on much-needed roadmap features and new product lines.

RetrospectionEmploying self-awareness in business will always be a prerequisite for change, helping to recognize when a

pivot is necessary. Unburdening ourselves from an archaic, on-prem server architecture and opting for a more

contemporary auto-scaled cloud solution, would be the shift we so desperately needed.

Although auto-scale was amongst the top benefits experienced from this migration, cost-savings was not one

of them. Despite solving our most significant technological deficiency, inability to auto-scale, we introduced

another, exorbitant cost.

As our newly provisioned, auto-scaled cloud architecture reached a stable state, addressing rising server

infrastructure and DevOps costs prompted a full system rebuild. The rebuild would be accomplished with the

use of a microservices design pattern and AWS Lambda serverless technologies. Although Serverless was not

our first cloud solution choice, its unique benefits quickly promoted it to the top of our list. Serverless' innate

ability to eliminate DevOps responsibilities from the software development process, was unprecedented.

Our AWS cloud journey wouldn't provide us with unlimited scalability right out of the gate, rather a flexible,

product rich platform, to build high-scale applications for years to come. The transition from an on-prem

monolithic architecture, to a Serverless microservices architecture, imparted many invaluable lessons to us

throughout the way.

17

Embrace ChangeHands-on vetting of new products, technologies,

and methodologies

One solution may introduce one or more

complication(s)

Make mistakes.Learn from them.

Move on.

Retrospection (cont.)

18

With these lessons learned, we can safely say that there is no one size fits all solution for modern SaaS

companies that will solve their scalability constraints. Fortunately, companies can deploy powerful tactics as

detailed in our cloud journey. Every situation is unique and will require slightly different approaches, but no

problem is too big to solve. What does exist is the opportunity to harness the power of change to solve these

problems, and with a bit of ingenuity and unconventional thinking, surprising results can be realized.

Serverless technology has opened the door to a world of possibilities for software companies looking to

simplify their development processes, reduce cost, and shorten time to market. It is essential to understand

that Serverless is not a magic formula and may not fit every use-case, notwithstanding all of its inherent

benefits.

About MasterStream ERP

MasterStream's products and solutions eliminates the time-consuming processes, complexity, and errors

associated with the telecom supply chain between providers, agents, sub-agents, and customers. Our

experience, expertise, and commitment to our craft continues to be our driving force as we continue to sustain

our position as the leading provider of automation solutions within the telecom industry.

Connect with us today to learn more!

1 (951) 277-4225 / 22324 Temescal Canyon Rd. Suite 200, Corona, CA 92883

www.MasterStreamERP.com

MasterStream ERP, the leading provider of Lead-to-Cash software solutions for the telecom industry