CleanSlate attains the Amazon DynamoDB SDP Designation

[Carmel, Indiana – June 8, 2021]:  CleanSlate Technology Group today announced that they have attained the Amazon DynamoDB Service Delivery Program (SDP), an integral part of the AWS Serverless Computing Services.

“We’re very excited to have received the DynamoDB SDP designation ,” says Chris Konow, COO at CleanSlate. “As a result of this achievement, we’ve reached the trifecta of service delivery for AWS serverless computing services with all three – API Gateway, DynamoDB, and Lambda – under our belt.”

Amazon DynamoDB Partners help customers deploy Amazon DynamoDB, a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. 

CleanSlate AWS experts utilize Amazon DynamoDB to build scalable and reliable modern applications in which it’s not necessary to maintain servers, and applications have high-availability automatically.

“This designation is a testament to our incredibly talented consulting team, who’re delivering technical solutions to clients at a very high-quality level aligned with the AWS Well Architected Framework guidelines,” says Darren Mills, Chief Technologist at CleanSlate.
To review a client case study highlighting an Amazon DynamoDB implementation, visit
To learn more about Amazon DynamoDB features, visit
To learn more about our Amazon DynamoDB capabilities, visit

How to Recognize a Monolithic Application

Monolith. The ominous name signifies something big, unmovable, and difficult to deal with.

And that’s exactly what a monolithic application is. At least in the long run.

A mountain. An iceberg. Something you can’t really change, move, and constantly must work around. Meanwhile, it’s casting a shadow on your day-to-day life, maybe eve n a threat, always in the background, like the Mountains of Moria.

Who wants that? Not this guy.

How to recognize monoliths

How do you recognize a monolithic application?

You probably recognize it subconsciously in the way you feel about an application when it’s brought up. It’s that application you internally cringe towards when someone mentions rolling out the next version. Perhaps it’s been around since the end of the third age (~6,000 years ago for you non-LOTR fans), nobody has dared touch it in 10 years, yet it’s performing a critical business function.

Maybe it’s that application your semi-technical business user built on their own, ran from their desk for a while before IT recognized it’s significance, and now its running in a container on your cloud environment. But you don’t dare touch it. The Jenga tower may fall.

Then there’s the application that always introduces cost and quality problems. Every time you ask for the simplest of changes, the development team comes back with higher-than-expected cost projections. 

Or worse, you must do a significant amount of regression testing across the application, the testing cycle takes forever, and you can always count on a few production bugs infesting the build rolled out.

All these scenarios can indicate you have a monolithic application. Yuck. Now what?

You’re stuck in that endless consideration to blow it up and start over somehow, spend a lot per tweak, or live with its current state, none of which are enjoyable processes for you to consider. At some point, the application becomes a legacy application you no longer upgrade, limiting your users to the feature set it contains, or spend a lot more than you want to keep evolving it for them. Unpleasant options all.

In a nutshell, the same characteristics that make a mountain so intimidating are the same reasons a big, monolithic application is painful.

How’d we get here?

Let’s time warp back to CS101 – Principles of Software Engineering with Dr. Brown-Jacket-With-Patches at State U. They taught you that tightly coupled designs were not as good as loosely coupled designs. What happened? You traded loosely coupled design and its long-term benefits for some short term business value.

Maybe you needed that app TOMORROW. Maybe you had staff with limited experience. Maybe you rushed it through production. Or maybe it was death by a thousand paper cuts over time – enhancement by enhancement.

“This is just for a few months” turned into business critical and it is still around, years later. Maybe the system designer wasn’t the best choice for the job. Whoops! Should have hired that consultant. It’s ok, we’ve all been there.

This all sounds familiar

Regardless of the ‘how’, you’ve ended up with a ginormous mass of tightly-coupled components over time.

Years ago, loosely coupled designs were accomplished by building more modular, reusable components – like functions or classes in object-oriented programming languages and platforms in the late 90s.

Maybe you encapsulated some business logic in a COM component referenced by ASP pages.

Then, things gravitated to more segmented, decoupled components like XML web services wrapping reusable logic called from frameworks that focused on messaging or user interfaces.

We all did the best we could with the tools we had.

A modern approach – a true advantage

Today, we have modern cloud platforms that allow more decoupling than ever – web API endpoints, AWS Lambda, Azure Functions – we even have serverless systems.

These modern platforms enable your business to have greater agility, flexibility, and speed – the real value of the cloud.

Now, if you want to fix a bug, you can fix a microservice that can be tested at the building block level. You can pull that component out and plug a new one in, much like swapping a hard disk in your disk array. And with modern DevOps and testing tools, that single component can be tested independently and replaced with much less impact and risk to the overall systems.

That’s the power of a well-architected, decoupled system – the antithesis of a giant mass of spaghetti code.

So, how can you migrate away from monolithic applications? How can you leverage the cloud and well-architected principles to achieve speed and flexibility? How can you increase the speed of delivery and improve quality? Are you ready to slay that monolithic dragon?

Contact us to learn more – we’re happy to discuss and design a path away from the dreaded monolith.

Nathan Hiscock is the Client Innovation Director at CleanSlate. He has an extensive background in helping clients fix their problems with innovative value driven technology solutions and collaborative vendor partnerships. Nathan is heavily involved with community engagements and strives to help others overcome adversities. CleanSlate is very fortunate to have Nathan on our team and for the great work that he provides.

CleanSlate attains the AWS Lambda SDP Designation

[Carmel, Indiana]: CleanSlate Technology Group today announced that they have attained the AWS Lambda Service Delivery Program (SDP), an integral part of the AWS Serverless Computing Services. 

“We’re very excited to have received the Lambda SDP ,” says Chris Konow, COO at CleanSlate. “Our partnership with AWS is a long-term strategic one, which we leverage to provide superior service for all of our clients.”
AWS Lambda partners help customers build or migrate their solutions to a microservices architecture running on serverless computing, enabling customers to build services and applications without provisioning or managing servers. Lambda is deployed to take care of everything required to run and scale code with high availability.
“This designation is a testament to our incredibly talented consulting team, who’re delivering technical solutions to clients at a very high-quality level aligned with the AWS Well Architected Framework guidelines,” says Darren Mills, Chief Technologist at CleanSlate.
Review a client case study highlighting a Lambda implementation.

Learn more about our AWS Lambda features. 

A Day in the Life: Molly Hyslop

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.

Microservices, Monoliths and Myths, for Developers

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


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.

5 Foundational Elements of Modern Application Development

These days, it doesn’t matter if you’re a non-technical founder or a full stack developer, you’d have to be living under a rock not to have been exposed to messages about the cloud and modernizing application development.  “Get apps built fast!” and iterate rapidly to keep up with the ever-evolving landscape of user needs.

However, with the deluge of information that exists on the topic, it might be hard to “see the forest through the trees” when it comes to the elements that comprise a modern approach.

I think it’s a good idea to level set, or agree upon, what is meant by the term “modern application development.”

There are five (5) elements that make up a modern approach to app dev:
(1) Microservices

Many companies start their business with (what’s defined as) a monolithic application because it’s the fastest way to go to market. The problem with this approach, however, is that if any one process experiences a spike in demand, the entire architecture is stressed and has to be scaled up to handle the load of that one process.

Source: Red Hat

By contrast, microservices (as defined by Red Hat) are an architectural approach to building applications that are distributed and loosely coupled, so one team’s changes won’t break the entire app.  Services are built to serve specific business functions, like a shopping cart.

These services are run independently and can be updated to meet any demand scenario. Development teams are able to rapidly build new components of apps to meet changing business needs.

(2) Purpose-built databases

As Werner Vogels, CTO and VP of Amazon.comsaid: “Seldom can one database fit the needs of multiple distinct use cases. The days of the one-size-fits-all monolithic database are behind us, and developers are now building highly distributed applications using a multitude of purpose-built databases

Instead of a single database, modern applications are built with decoupled data stores in which there is a one-to-one mapping of database and microservice.  It is no longer a sound recommendation to have a single database act as a single point of failure – instead, choose the database that best fits the needs of the application.
(3) Serverless

According to Serverless Stack, “serverless is an execution model where the cloud provider (like AWS or Azure) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code. The code is typically run inside stateless containers that can be triggered by a variety of events including http requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), etc. The code that is sent to the cloud provider for execution is usually in the form of a function.”

AWS introduced the concept of serverless in 2014 with the launch of AWS Lambda, a service that lets companies run code without provisioning or managing servers. Going serverless frees companies to focus on activities that differentiate, like product innovation, instead of the endless (and often expensive) task of managing physical hardware.
(4) Automated release pipelines

Continuous integration (CI) and continuous delivery (CD) embody a culture and collection of practices that enable modern application development teams to deliver code more frequently and reliably. The implementation is commonly referred to as “CI/CD” or “CI/CD pipeline”.
Source: Synopsis
CI/CD is one of the best practices for a devops team to implement that enables teams to focus on meeting business requirements, code quality, and security because deployment steps are automated.
(5) Continuous security

According to Werner Vogels, CTO and VP of in this post, “In the past, many companies treated security as if it were magic dust—something to sprinkle on an application after it was ready for release. This doesn’t work well in a continuous release cycle, so organizations had to take a new approach to security, building firewalls around the entire application. But this also introduced challenges. The same security settings were applied to every piece of the application, which is problematic if an application is built with independent microservices that may need different settings.”

“For this reason, in modern applications, security features are built into every component of the application and automatically tested and deployed with each release. This means that security is no longer the sole responsibility of the security team. Rather, it is deeply integrated into every stage of the development lifecycle. Engineering, operations, and compliance teams all have a role to play.”

The role of DevOps isn’t just about development and operations any longer.  IT security must also play an integrated role in the full life cycle of your apps.  As a result, the term “DevSecOps” has emerged to mean planning for application and infrastructure security from the start.

So, do you need ALL of these in order to be considered modern?  No. 

To us, it’s all about evolution – it can take time and intentional steps to adapt. 

But adapt you must.

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)