Three Things We Learned Building cloudtamer.io

Last updated on February 6th, 2023 at 1:58pm

The need for cloudtamer.io was identified from our experiences helping multiple National Security customers deploy accreditable, scalable, and governable systems hosted by commercial cloud service providers (CSPs) like AWS and Microsoft Azure. When we looked around for existing solutions, or even groups of solutions, we couldn’t find an off-the-shelf capability which addressed all of our customers’ needs. We internally invested in and developed cloudtamer.io to provide account management, budget enforcement, and compliance automation to customers who face, or expect to face, governance challenges in operating their CSP-hosted systems.

We learned several lessons over the last year as we prepared cloudtamer.io for launch this week at the AWS Public Sector Summit.

Here are three things we learned in the process. Some of these lessons are particularly relevant to professional services organizations who are introducing a product offering, while others are applicable to all organizations launching a new product.

Strive to be mostly right, but be prepared to change

Our first challenge was selecting each of the elements in our initial technology stack. In our professional services engagements, we are typically constrained to using legacy technologies. (Even in 2018 we still run across an occasional Windows 3.1 box deployed in a customer’s network!) So it was exciting -- and daunting -- to be able to consider a wide variety of available options. While I knew our choices would set the foundation for a year of development, I also wanted the team to focus on product development and not be too distracted by the continuing evolution of technology trends and adoption curves. Borrowing a quote from Jeff Bezos, we strived to be “mostly right”. We knew we would make some decisions we would need to change, but we didn’t obsess about them during the development process.

I’m very happy with our decisions to use Go on the backend and Angular on the frontend, as well as our general microservice and container-based architecture. We were able to take advantage of a rich ecosystem of open source Go and Angular components and our team developed expertise in both platforms quite quickly. The microservice and container-based architecture has helped testing and automated deployment, and has forced us to define stable and clean APIs between system components. This has allowed us to respond to requests for automated integration with existing provisioning and billing systems.

However, not all of our early decisions were as successful. Halfway through initial development we switched from another open source container orchestration system to Kubernetes (K8S). We initially felt K8S provided more than we needed and wanted to avoid the startup failure cliche of trying to apply Google-scale technologies to much smaller scale problems. Market consolidation, the establishment of associated and supporting tools, and the increasing availability of DevOps staff with K8S expertise and experience caused us to re-evaluate this decision. We were able to make the transition with a minimal impact on the development team. Our DevOps team switched over all of the various environments to K8S within a single sprint, and the team has been evolving environments ever since to provide logging, monitoring, and overlap networking enhancements.

Lesson: Beware of ‘analysis paralysis’ when it comes to choosing among various technology options. Make an informed decision that allows your team to move forward, and get comfortable with the fact that a change may be needed down the road.

Open the flood gates to feedback, then triage

Figuring out how to gather and manage customer requirements was just as, if not more, challenging for us then solving the technical problems. In a professional services engagement, the customer dictates requirements and constraints on how, where, and when the team does its work. While there is usually a back and forth between us and the customer, we generally do everything the customer requests.

With cloudtamer.io, we were faced with many different customers, all with unique challenges that we had to build a product to support. We had to rethink how we engaged with customers as well as how we grew our team. As with our technology choices, we had many more options to explore and select then we were accustomed to having.

It’s critical during initial product development to gather as much input as you can from real customers using your solution. We were very fortunate to work closely with three public sector organizations who trusted us to deploy cloudtamer.io into their environment and were willing to invest their time to evaluate its effectiveness and suitability. Feedback is great, but you usually get more than you can immediately address. So it is important to triage, prioritize, and then communicate back decisions to all of your users.

We also did multiple demonstrations each week last year. This also produced some excellent insight into desired features, pricing approaches, and deployment models. We appreciated having potential customers take the time to share their problems with us and we gained a lot of insight about roadblocks they were facing in increasing their adoption of the cloud. But we had to balance this feedback against the focused scope of our product; cloudtamer.io would never launch if it tried to solve all cloud-related issues.

Lesson: When you’re coming from a professional services mindset, it can be tempting to try to address all feedback received. You need to put in place multiple avenues to get feedback, but you must first have in place a method for triaging this feedback.

Leverage services expertise to inform development

We also had to establish a lean startup product culture and build a team inside of a public sector professional services company. In professional services work, you need to align your schedule, behavioral norms, and sometimes even your attire with your customer’s expectations. Everyone on the team is not only an individual technical contributor, but also a brand ambassador for the company. Most modern commercial software developers and DevOps engineers are used to working in a very different environment. We had neither the time nor the resources to establish a distinct corporate entity and associated policies.

The first members of the development team had direct experience with the customers who inspired us to develop cloudtamer.io. It was important for us to leverage this experience and ensure new team members had a similar understanding of our customers’ needs. So we augmented our traditional Agile scrum development process with a distinct Kanban feature board to provide detailed descriptions and acceptance criteria. Marketing and sales provided input to the stories and epics in this board. Developers then created their stories and epics to realize these capabilities.

Lesson: If you have professional services team members who are very familiar with your target customers’ challenges, you have a distinct advantage. Bring these resources onto the product team to inform development. Going forward, maintaining a dialogue between the professional services and the product sides of the business helps to drive the right development decisions and build camaraderie across teams.

I’m extremely proud of what our team has accomplished with cloudtamer.io, and excited to see how much we can help our customers address their cloud governance challenges.