Is Your Start-up Production Ready (Part 1)

Part 1: How to Know When to Go

At 2bcloud, we love to collaborate with our peers and trade ideas on how to help young companies move faster and create stronger products by using all that today’s cloud systems have to offer. That’s why we sat down with our friends Shiri Hochhauser, Sr. Partner Technology Strategist at Microsoft, Alex Freidman, CTO of Opsflee, Israel Aloni, Director of Cyber Security at KPMG Israel, and our very own Itay Malka, Cloud solution architect team lead – experts on cloud architecture, DevOps, Kubernetes, and cybersecurity – for a panel discussion on production readiness. 

In this two-part series, we hear from top cloud technicians and consultants on how companies can achieve production readiness, speed, efficiency, and performance through the cloud. In the first part of our series, we’ll focus on what production readiness means and how to know if your company is production ready. We’ll also dig into how tailoring your cloud supports DevOps to catapult start-ups toward their goals at breakneck speeds.

What does “production ready” mean, and how can we know when an environment is production ready? Is there some kind of checklist or a specific time when we know for certain that this is the time to advance?

Alex: I don’t think there’s something specific. There’s a lot of checklists one could use to verify that a product or feature is production ready. But there’s no universal checklist, no silver bullet, so to speak. Of course, there are best practices and then each company needs to decide from its own expertise which of the best practices it wants to adopt when they arrive to production. A start-up can set this time in a number of ways – from the first paying customer, or the staff size, or the number of requests in the SaaS system – it’s really fluid. 

Shiri: I’ll add that in relation to software vendors, becoming production ready has a lot to do with your ability to deliver on your SLA. That means there are certain criteria that need to be met in regards to scalability and the capacity to support the workloads properly. Being production ready also relates to redundancy and understanding what to do when things go wrong and how to stay within your SLA’s time frames when that happens. Production readiness also has to do with security requirements that are drawn from the target customer’s specific industry. So I would say the three main qualifiers of production readiness are scalability, high availability, and security.  

Itay: I agree with what Alex and Shiri have said here. At the end of the day, there isn’t anyone best practice that everyone should work with, but there are a number of parameters that can help us to define what production ready means. 

I find that the most important factor in becoming production ready is having the ability to imagine what the most extreme situation would be for your product. For example, what would happen if tomorrow morning the system falls or if there are really high volumes (this relates to the number of requests in the SaaS and the number of staff on hand to deal with them)? You need to know if the infrastructure you are running for your product is equipped to clear a massive number of requests. 

Israel: On the security side, scalability and security are crucial to determining if you are production ready. It’s important to think about security at scale. There are a lot of small things to consider, but as a strategic directive, there comes a moment when you need to mature and say, I’m not settling for the minimum scaling abilities, I don’t want these processes to be partial or manual. Cloud-based start-ups and SaaS companies can become production ready rather quickly, but without scalability, going to production will only make problems.

I recently heard a saying that really resonated with me: Everything fails. In the end, every system is going to collapse. Most times, since start-ups are very focused on bringing the first customer and sprinting forward, something is always forgotten. So, in your experience, what is the most common mistake that you encounter in the “production ready” stage?

Alex: In general, it’s important to have the understanding that you must invest in infrastructure. This is not always clear to the product people, those who are leading the business, because they don’t see an immediate benefit in infrastructure investment for the product. But we see that time after time, companies that spend a few extra weeks creating the right infrastructure see the fruits of that labor later down the road. Another safeguard against failures that deal with production readiness is understanding the benefits of using managed services. When companies skimp on these, they often miss things that become problematic later. 

Shiri: I think there is a real need to separate what you need to run now from strategically thinking about what you will need in the future. Many times, we use a managed service that we don’t need at this very moment, but that we know will be essential to have on hand down the road. For example, we want to be able to utilize something like geo-redundancy with the push of a button when we need it, and not try to develop these capacities in the midst of growth. This flexibility is one of the most beautiful aspects of the cloud – you don’t have to deploy all of the services at once; you can develop them and add them as needed. 

For example, I work with two start-ups who implemented Kafka on their own because they needed to have some kind of queue. Now, managing Kafka is like a full time job for them, and they want to get out of it. So, it can be wise to engage managed services early on to simplify operations in the future. Future needs are always something important to take into account when evaluating production readiness.

Itay: There’s always a trade-off between high availability and cost that start-ups have a hard time balancing. Most start-ups want to pay less and go live with the minimum amount of resources required. On the other hand, the managed services that tend to be more expensive provide better orientation toward the future. This question of balance is something I run into on a daily basis, and start-ups need to look into thoroughly before launch. Shir brought up the benefit of filling in gaps using managed services, but that really depends on your point of departure. If you are uploading your first configuration or architecture to the cloud, then the managed services are easy to adjust as your product and company progresses. But if you are migrating to the cloud from something that was built on premises and/or has dependencies on older program versions, then there is a chance that managed services won’t be suitable. Since there can be many exceptions to the rule, companies need to know whether or not their current setup can actually be improved with managed services.

We encounter a lot of cases in which production-phase start-ups come to us with a CI/CD that isn’t optimized. Is it possible to do production at scale if the CI/CD pipelines aren’t properly arranged? Does it make sense to carry out testing in this stage?

Alex: In general, the technology makes it relatively easy to handle it; the CD, GitOps, and flux will be accessible even in production. The level of difficulty will mostly depend on the size of the team that’s available to work on the environment. If there are enough people on the development team, then it can be ok, but still, it’s better to perform these optimizations at an earlier stage.  Equally important, if you decide not to do the optimization, then you need to understand what the price will be for that, both today and down the road. You need to understand how much the cost will be for the staff to keep things in order manually as workloads fluctuate. 

Itay: I think it’s important that start-ups only upload CI/CD flows are properly organized and optimized. To understand why this optimization is so important, we need to grasp the purpose of the CI/CD to begin with, which is to simplify deployment processes and run checks at a greater speed than we could do manually, without creating errors or vulnerabilities. So simplification and automation can only improve performance if the CI/CD is optimized. Optimized maintenance comes from centralization. When you create pipelines through Azure DevOps, you get full command of the source code, no matter if it’s your own or taken from a third party. 

In terms of security, there is an added value in managing everything from one place. If we are talking about the CD process, for example, we are not only able to simplify the working processes but we are also able to monitor it in real-time. And we can look back at what’s been built to understand where errors are coming from. We can also facilitate rollbacks with relative ease. All of this allows us to work at a faster pace and on shorter deadlines, because with an optimized CI/CD, we are able to continuously validate infrastructure code and avoid repeating mistakes.  

I want to add one last thought on a huge advantage we take from implementing CI/CD, which is the separation of the environments. Keeping our production environment from our development environment, where we do our testing and such, ensures that what’s not working in the development environment doesn’t end up in the production environment and vice versa.

We all want to sell, but we don’t want to find ourselves in a place where customers have signed on but we aren’t really ready for them. Is there a specific point in time that you would say is ideal for reviewing your production readiness?

Alex: Well, it’s better to do this sooner rather than later, but usually these kinds of reviews happen naturally during times of growth when your traffic or staff is increasing. In fact, start-ups usually end up bringing us into the picture when the technical infrastructure starts to feel the weight of such changes. 

Israel: Another good time to perform a check is when you are making strides in development if you are adding new features and capabilities. It’s something you should also look at before you present your financial picture to investors. 

Itay: The cloud itself offers a lot of tools and guidance for performing assessments of production readiness. The more a product design is tailored to the specific cloud environment, the better the assessment will be. You need to have some clear parameters in place to understand what exactly needs to be ready in order to launch. 

Shiri: I don’t believe there’s such a thing as a “right time” to perform this check, but I think in general, whatever point you find yourself at, it’s a good time to make this review. Understand where you stand in regard to your goals and also take into consideration where your customers want to be. Every time you encounter something new, you should think about how the cloud can handle it in a way that will make life easier as you go along.  

For more information on production readiness and cloud management for performance and optimization, see our extensive library of articles by 2bcloud experts, or contact us for a one-on-one assessment.