MOLLY HYslop

Enterprise Sales Executive

Molly is an experienced business development and sales executive with extensive experience in cloud consulting for AWS and Azure. She makes a positive impact in every interaction she has with her clients and CleanSlate’s partners. Molly’s positive spirit drives her to view situations with the “glass half full” and her competitiveness aids in her success on the sales team. Outside of work, Molly relaxes by going on walks, reading, and watching her favorite Netflix and Hulu shows.

Q: Can you give a brief background on your career history?
A: I started out my career with Hewlett Packard Enterprise at one of their call centers, as an Inside Sales representative. During my time there I was fortunate to experience many new opportunities supporting different regions, interacting with different business units and leadership while selling different products. From there my career evolved into sales enablement and business development. The last 5 years have been focused on business development; cultivating new relationships for business opportunities. Now at CSTG, I have the opportunity to not only cultivate but maintain those same relationships and continue to support my clients. I enjoy getting to support clients throughout the entire “sales cycle”.

Q: What does your day-to-day look like at CleanSlate?
A: My day general consists of the following: meetings with clients, meetings with new potential clients and reaching out to schedule meetings with potential new clients for CSTG, with a lot of follow-up with partners and clients in between.

Q: What do you like about working at CleanSlate?
A: I enjoy working with my team, they are great people and hard workers. Who doesn’t appreciate that?

Q: What gets you excited about your everyday work?
A: A new challenge everyday- there is also the opportunity to learn something new.

Q: What are you looking forward to at CleanSlate and in your career?
A: Looking forward to building more client relationships and bringing them value.

Q: What are some non work-related activities that you do in your day-to-day? (this probably looks a little bit different than it did pre-covid)?
A: I enjoy/need some type of physical activity; usually walks in the neighborhood during lunch or for an afternoon break. After work, I enjoy reading books and relaxing watching my favorite Netflix/Hulu shows.

Q: What are one or two long-term goals you have?
A: Goal is to continue to create awareness of who CSTG is, so far, I feel like I have been successful, but we all know sales is never over and your consistently starting over so that goal will continue.

You see the term microservices tossed around often on powerpoint slides, webinars, and sales glossy handouts, but it’s one of those words that we seldom discuss in detail as developers. Let’s cut through the noise and talk about what this means to you, a developer.

Why Microservices

AWS themselves have a few things to say about this, and we’ll touch on each of them shortly.

• Pick the Right Tool for the Job
• Improved Resiliency
• Refined Cost control
• Improved Team productivity
• Reuse with Composition
• Safely experiment, Reduce Failure Impact
• Accelerate Tech Adoption
• Deploy Faster, and Safer

Pick the Right Tool for the Job

One misunderstanding about this is that it’s just a buffet of programming languages and stacks that you get to pick whatever you want to use. It promises freedom from bureaucracy telling you what to use.

Is it maybe a little bit of that? Sure. But that’s not really the intent. It’s a lot less about language choice, and a lot more about systems design.

Netflix, for example, uses a concept they call the “Paved Road.” There are a core set of languages, stacks, libraries, and services that are very well understood. And most importantly, very well supported internally. There is flexibility, but it’s the most-supported “road” to stay close to.

Can you wander off-road? Sure, but you’re a little bit on your own at that point, and need to make that decision intentionally, and do extra things to mitigate risks.

So what is an example of “the right tool” not being about programming languages? Data stores. Specifically, picking the correct, purpose-built data store for the service.

If the service is going to be highly transactional, with purely relational data, Redis is not going to be the best choice. If the service requires burstable high-throughput writes of non relational data, DynamoDB may be a better fit than a large RDS instance.

To sum it up:

• It’s not 30 programming languages
• Stick to Paved Road (Netflix example)
• Purpose-built data stores (recommended practice)

Improved Resiliency

Resiliency is crucial when architecting systems. Failure should be expected as a rule, not treated as an exception. There are things beyond control, but not beyond design. Identify failure modes, and compensate for those from the beginning.

Microservices allow you to take the many different parts of your system and separate them into controllable pieces that all have their own failure modes. What happens when one service fails? The entire system need not come crumbling down. Instead, it may just result in temporary availability issues of one part of the system. How about an example?

Take a look at the entirety of Amazon eCommerce. To start, you can break this into a few crucial components:

• Inventory Listing (How do we see the thing?)
• Adding things to carts (How do we select the thing?)
• Financial transactions (How do we buy thing?)
• Logistics and Delivery (How do we get the thing?)

Taking a look at financial transactions. One could say for an eCommerce company, and outage of this functionality would be the end of the world, and we’d call the whole thing “crashed”. With a monolith, you’d be right.

However, just because you can’t pay for a thing doesn’t mean things currently on trucks just… stop being on trucks on the way to you. Nor does it mean you just can’t list any items. And it also doesn’t mean you can’t still shop and select items you want to buy. You know, when the payment service recovers.

To sum it up:

• One service failing should not be a total system failure
• Inventory, add to cart, payment, shipping, should be independent and fault tolerant

Refined Cost Control

In a monolith, the environment must scale up to the demand that is required by any part of the system. WordPress is a great example of this. Regardless what part of the CMS is experiencing the demand, the entire thing must grow to compensate for this.

However, if this were broken apart into independent services, those could be scaled independently, leaving the other services right where they were. And metrics can be granularly collected on each service to pinpoint exactly which one is experiencing demand increase.

If the internet is giving your latest article a great big hug, you shouldn’t need to scale the authoring service if you’re the only one authoring content.

To sum it up:

• Each service can be measured independently
• Each service can scale independently
• Each service can have it’s own approved quotas and alerting

Improved Team Productivity

Developing features and remediating defects in a monolith requires a wholesale reproduction of the entire system and stack, just to get started. Depending on the size and complexity of such a monolith, even the most sophisticated development environments can be sufficiently taxed for resources.

There’s also the “where is the problem” aspect of tracking down the issue, finding the code culprits, then fixing (hopefully) the problem. The entire stack then needs shoved through the CI/CD pipeline, and redeployed in its entirety, often involving some system-wide downtime.

Alternatively, with microservices, it’s easier to track down an individual service’s failure (thanks to more fine grained alerting, logging, and monitoring). This then means there is less complexity to reproduce, and find, and fix, and push, and redeploy.

As discussed above, it’s possible for this entire process to be done with minimal interruption to the system if we’ve architected for expected failure modes.

To sum it up:

• Far easier to collaborate via api contracts
• Faster and easier to unit test and develop against specific services
• Faster to run a service vs an entire stack
• Mocking stacks to api contracts

Reuse with Composition

If we think about the Single Responsibility Principle in software design, and apply the same line of thought to systems and services, a fascinating pattern emerges. So long as we honor our existing service contracts, we can enhance our service as feature requirements change, with impact limited to only the responsible service.

Additionally, it often happens that a service already exists that can just be leveraged by another system as business needs change. As an example, a service that aggregates metrics and analytics data could then be orchestrated into a new service to collect user behavior data, uptime reporting, resource utilization, and much more.

The additional use cases require changes only to one service, instead of something that threads and snakes its way through the monolith. Or worse, complete rewrites of previously-working functionality.

To sum it up:

• New use cases don’t require rewrites
• Services can consume others as new features are made available

Safely Experiment, Reduce Failure Impact

Experimenting with new technology and design patterns used to be quite difficult in a monolith. One particular challenge is the codebase itself; keeping in sync with the rest of the changes while you develop your experiment. Using a service based architecture reduces the amount of “other” code you are competing with as you try to migrate to a new pattern.

As an example, trying to migrate to leveraging state machines for state management. It’s difficult to do this to an entire monolithic application, but can be more manageable when limited to a purpose-built, focused service, while not impacting others.

To sum it up:

• Experiment in controlled isolation
• Easily deprecate failed experiments
• One bad feature doesn’t bring down an existing system

Accelerate Tech Adoption

As an example, adopting new logging and metrics tools is scoped down to a single, focused service. And if the experiment is deemed a failure, the impact of that failure is restricted down to just the service, while the rest of the system can still perform as before. Consider it a canary, of sorts.

And any time a new service is being considered, it’s a perfect opportunity to use it as a test bed for a new emerging technology or a different design pattern. The risk is tightly controlled, and more easily measured and evaluated.

Additionally because there is less functionality and responsibility in a single microservice, there is also much less to grok for new team members when trying to onboard. These new contributors can more quickly bring their expertise and new ideas to the project, demonstrate the ideas, and perhaps kick off a broader adoption in other services in a planned and coordinated fashion.

To sum it up:

• Allows adopting new tech in isolation vs entire stack rewrite
• Allows new team members to bring new experience to the team and freedom to more narrowly demonstrate future tech

Deploy Faster, and Safer

Ah, deploy day. Or night. What a time to be alive, right? Middle of the night, sure hope traffic is low and everyone is logged out. Hope it all goes as planned. Oh it didn’t? Hecc, how do we unravel this, redeploy the whole thing another time after we fixed this.

That’s life in the monolith. Personally? I don’t miss it.

Instead, it’s less stress when focusing on a single service. Consider possibly a canary or a blue-green deployment. The code changes are smaller, the build and test times are faster, the deploy and go-live times are minutes, not hours.

Problem with the deploy? You still need to roll back, but the rest of the system is left much less disturbed, and the previous working version will be reverted to via DNS or redeployed much faster than an entire monolith.

To sum it up:

• Deploying the world vs one service
• Downtime is shorter or non-existent
• Rollbacks are faster

Recap

Breaking a monolith into loosely-coupled, event-driven services offers some amazing potential benefits in the areas of cost, flexibility, and security.

This is not to say there won’t be challenges. Microservices done poorly are worse than a mediocre monolith. The complications will normally come in a few flavors:

• Service discover
• Versioning
• Couple-changes
• Breaking contracts

With this in mind, make sure to have a discussion with your team. Identify those challenge points and consider them from the start as you start to adopt an application modernization effort, or green field development.

David is the AWS Technical Architect at CleanSlate Technology Group. Coming from over a decade of custom application development, deep expertise in CI/CD and cloud operations, he brings a breadth and depth of experience to all teams to advise, direct, and implement solutions that surprise and delight our clients. With a focus on developer experience, collaboration, and state-of-the-art architecture and strategy, David works closely with our partners, vendors, clients and staff to ensure CleanSlate Technology Group advises and implements the best of breed solutions with a focus on quality, resiliency, cost management, security, and privacy.

Source: Red Hat

Dave is the Director of Marketing for CleanSlate Technology Group. An experienced marketing & technology professional with expertise in developing and executing strategic marketing programs, building exceptional teams, and driving ROI. His past results include 705% return on ad spend, 90% increase in lead generation, $1.2M gross sales in 9 months, 67% boost in organic search traffic and a 448% rise in online testimonials. He has led a team of 10 and controlled a $6.1MM budget. (Source: LinkedIn)

Liz Watson

Financial Analyst

Liz has been at CleanSlate for about three years. She began in a part-time capacity as a Financial Analyst, and a little over 2 years ago came on full-time and really took on the role she has today. Outside of work, Liz spends her time working out and with family, ending most days loading a tee and throwing batting practice at ProX in Westfield to her youngest daughter. 

Q: What is your role at CleanSlate?
A: My role has evolved significantly over my 3 years at CleanSlate. I began in a part-time
capacity as a Financial Analyst, focusing on Accounts Receivable and some occasional
other tasks for our controller. A little over 2 years ago I came on full-time and really
took on the role that I have today. That role involves all aspects of project and
assignment setup, the billing and invoicing for our Services practice, managing our
contractors’ hours and billing and providing data points to our leadership team so they
can use that information to make decisions on the day to day and long-term operations
of the company.

Q: Can you give a brief background on your career history?
A: I began my career as a consultant and developer for Crowe Chizek in South Bend. After
moving to Indianapolis, I did some technical writing as a contractor before ultimately
deciding to stay home to raise our children. Then in 2013, my husband and I opened
our first Jersey Mike’s subs franchise, followed shortly thereafter by our second
location. I ran the day-to-day operations for both stores as well as all the back-office
tasks (human resources, bills, payroll, etc.) After 4 years of operating our stores, we sold
them in 2017 and I took some time off before I began with CleanSlate in 2018.

Q: What do you like about working at CleanSlate?
A: The people and the flexibility. CleanSlate provides a wonderful, flexible environment
where I feel like I can give 100% to both my work life and family life without having to
compromise either one. There has never been a group of people I have enjoyed
working with more than my coworkers at CleanSlate. They are smart, creative,
hardworking and make work fun and enjoyable.

Q: What projects are you currently working on?
A: No specific projects currently but looking to streamline some reporting processes even
more this year to be able to provide the leadership team with even better data to use in
their planning and day to day operations.

Q: What skills are you currently utilizing in your role?
A: My organization skills have really helped me to streamline the invoicing process and be
able to conduct our month end closeout more efficiently and my technical skills working
within Salesforce and utilizing some previous experience with report building.

Q: What teams are you currently working on?
A: I work primarily on the Administration/Finance team but cross over to the sales and
delivery teams as well providing answers to our salespeople and project managers on
current projects and future opportunities they may be working on.

Q: What gets you excited about your everyday work?
A: Even though I have a lot of the same tasks that I do on a regular basis, there is always
something new to tackle as well. I like being able to problem solve and provide
answers to the team and look for ways to make my processes more efficient.

Q: What are you looking forward to at CleanSlate and in your career?
A: I just want to continue to help CleanSlate grow and be able to provide our leadership
team with even better data as efficiently as possible.

Q: What are some non work-related activities that you do in your day-to-day? (this probably looks a little bit different than it did pre-covid)?
A: I always make time to get a workout in. It makes me a better employee, wife and
mother when I am taking care of myself physically and mentally. Usually, my day ends
with me loading a tee and throwing batting practice at ProX in Westfield to my youngest
daughter.

Q: What are one or two long-term goals you have?
A: As of right now I am happy with where my career is. I feel like I have a great balance
that has me feeling fulfilled professionally but also present for my family especially as
we enter these last 5 years of having children at home with us.

Q: Any fun facts about yourself, or anything else you’d like to share?
A: I am an identical twin. We have the same college degree (CIS from IU). Was born and
grew up in New Jersey before moving to Indiana at age 11. All these years later, I still
miss the food and I make Casey bring bagels back every time he flies out there for work.
Took our youngest to the 2019 Women’s College World Series which has always been
one of my bucket list items. It did not disappoint. Can’t wait to do it again.