CleanSlate Technology Group attains the AWS Lambda Service Delivery Program (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

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.

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 Amazon.com 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)

A Day in the Life: Liz Watson

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.

IT Leaders Must Rise to the Occasion

According to a study by Gartner in 2021, 69% of director boards are wanting to accelerate digital initiatives in response to Covid-19.

Are you vulnerable?

Are you and your company ready to rise to the occasion?

In the following short clip from a webinar we hosted on 2/24 entitled “Achieving Business Agility through Modern Application Development”, Chris Seitz, CleanSlate’s VP of Product and Delivery, discusses the importance of organizations improving their IT capabilities in order to support change.

 

Interested to hear the rest of the discussion? Watch the full webinar here.

As a senior IT executive and project leader, Chris has had the opportunity to work with many of the best companies and talented professionals in the industry. His focus on strategy, architecture, and technology has allowed him to build a successful track record of delivering technology solutions that drive outstanding business value. (Source: LinkedIn)