Is Your Start-up Production Ready? Part 2

Part 2: Ensuring Security and Scalability

 In the second part of our series on production readiness, we highlight the important role that security and scalability plays in the success of all businesses on the cloud. In the interview below, our panel of cloud experts –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  – bring us up to speed on how young companies can use the cloud to ensure they have the optimal security and scalability infrastructure to support them during launch and growth.

In Israel, which is popularly known as the “cyber state,” security is supposed to be a real no-brainer for start-ups. But we know from experience that this isn’t the case. Start-ups tend to confuse security and regulations, sometimes thinking that being compliant is enough to maintain security. What do you all see happening with start-ups in terms of security?

Israel: Well, even though Israel is called the start-up and cybernation, we know that what we export isn’t necessarily employed inside the country. But in regards to your question, I am glad that you brought up the common mistake in thinking that compliance, regulations, and security are one and the same. People even use these terms interchangeably, although they have important differences.

There’s a big gap in the perception of compliance versus the perception of security. Many companies think of security and compliance as one complete circle, if you are on point with compliance then you must also be secure and production ready. But this is not so. Of course, being compliant is really helpful for the business and for encouraging investment and many other things, but security and security at scale is something completely different. I’ll give you a simple example. If you get your stamp of approval that you are compliant with this or that regulation, but a minute later someone goes to production with an improperly configured VM that leads to a data breach, then what good is the stamp of approval? In such a case, compliance didn’t ensure security.

Start-ups need to think about security in practical terms in the production environment. I mentioned security at scale and the key tool for creating it is automation. There is some overlap between cloud architecture and DevOps and security. The cloud’s automation abilities create important and practical safeguards for creating security at scale, and they are much easier to use now than in the past. You can update infrastructure codes and security policy codes quickly. The system functions according to policy and doesn’t allow for the creation of elements that violate it. This helps you guarantee you are building your system properly from the beginning, which makes your system less vulnerable.  Automation also offers non-stop monitoring capabilities that are crucial for security. If I’m an Azure native, I can use the tools in the compliance and security center and receive a warning each time there is a violation or a security anamole. If you take just one thing away from what I’ve said tonight, let it be the need to leverage automation for building correctly and monitoring effectively.

Shiri: I notice that many start-ups, especially in the initial phases, are a bit naive when it comes to security. They wonder, who would want to attack me? I’m not that interesting. To these companies I say, the minute you land that first big client, you will be very interesting indeed, but at that point, you won’t have enough time to secure yourself against attacks. In the cloud, everyone is a target, all the time. I saw an experiment where someone opened a VM with open ports and it took about 2 seconds before it was attacked. And there are security-related issues that few start-ups recognize during development. For example, I work with a start-up that doesn’t have access to sensitive information but is connected to all kinds of webhooks that allow them to publish social media posts in their clients’ names. So to help start-ups, you need to help them think about worst-case scenarios, like what would happen if a hacker managed to post elicit material to a client’s social account. This example may feel extreme but everyone needs to consider things like this to encourage making the proper investment in security at an early stage, even when they all focus is on development. Even if you don’t have a lot of needs for security features upfront, you should take a service that will enable you to have these capabilities built-in, because adding them at a later stage is far more complex and time consuming.

Security is important, but what if I don’t have any knowledge or skills in cybersecurity? How can I get that information?

Israel: There are definitely things that can be done and should be done at an early stage to ensure that you are accounting for security, compliance, and privacy regulations (depending on what your product does) into the product’s design. It’s important to do this in the pre-production phase, when things are easy to correct, as opposed to trying to fix things later.

Sometimes companies don’t need to have security maps drawn for their product but can get by on simply figuring out what not to do. For example, I’ve met with start-ups who were collecting and holding on to sensitive client data, without their business having a need for that data.  For them, holding onto sensitive data was a prime example of what not to do, as it would put them on the hook for numerous regulations and drive up the cost of production. These determinations can be made easily in the design phase and we can then plot the right course for the architecture that can enable protections at a later phase. Adding security features after production is difficult – nobody wants to redo their architecture on a quarterly basis. These things need to be planned in the design phase, especially if you don’t have expertise in cybersecurity.

We speak a lot about production at scale, but there is a common feeling at start-ups that scalability and high availability are something that will only become relevant in the far-off future. So start-ups don’t usually think about things like using a load balancer or reviewing zone availability from day one. Is it possible to go to production without taking these details into account? If so, then what are the most important considerations for ensuring that start-ups will still be prepared for scaling and high availability down the road?

Itay: From the first stage, you need to look at the managed services and ensure that you will have the ability to scale in the moment that you need to.  You really need to think about the features you will need in the future before going to production.

Alex: In terms of the absolute must-haves for a start-up, I think it’s more a matter of understanding the trade-offs involved in whatever service you give up in the name of cutting costs. I can give you an example from my experience. I worked with a company that decided to cut costs by not creating separate environments for their intel and production. In the end, when they experienced a problem, the production environment fell for a few hours. So in the beginning stages, it’s really important to understand what kind of situations can result from cutting corners, what’s the real cost for those.

Israel: Start-ups need to understand the business implications of everything that is happening on the technical side. For example, if you opt to do things manually as opposed to using automation, you need to know how that’s going to impact your bottom line. If your system goes down for a few hours and you need to bring it up again manually, you need to understand how much money that downtime will cost. Taking the discussion to the business side of things doesn’t necessarily mean that you will invest in every service out there, but that you will understand the meaning of not having one service or another, which is really critical in the SaaS era.

Shiri: In my view, one key early-stage consideration is region choice. This seems like a no-brainer, but not all regions are created equal. There are regions that don’t have availability zones, like US West, for example. . Even at the level of cost, if you practice spotting, which is basically like bidding on VMs to acquire them at a cheaper price, then the cost will be largely dependent on the region and the demand for VMs there. The pricing differences can be staggering.   Moving locations after production is not a fun process, so it’s important to carefully select your region from the outset, especially if you have a lot of CPUs. There are different ways to select a region. You might want to be in a region that receives things a bit sooner than others, or you can go according to parity, or even choose a region according to your customer base’s location. So the region is an important consideration from the viewpoint of cost and latency.

In terms of development, when you develop something, you need to think strategically about whether or not it impacts the core of your product. If it is, dedicate time to it. If it’s not, then outsource it. If it doesn’t have really specific technical requirements, use a managed service. Even if it’s a feature you will only need, later on, create it in the development stage so that you will have the possibility to use it in the future.

We’ve been talking a lot about looking toward the future. For example, we know that logging is important for long-term success,  to be able to properly research and understand events, and to develop the product. What can we do in the early stages, when the environments don’t have a lot of traffic, that can provide some value in the future?

Itay: Logging is basically a cover-all for every pillar we have been discussing. It applies to infrastructure, security, computing, and even CI/CD pipelines. We really need to make sure that we have all the output we need because this insight is what helps us to develop the application and more sophisticated features. Logs help us to understand how to manage costs and how to manage the product. If we want to look backwards or even to see in real-time what caused a system to fall, or if I want to research how to become more efficient, I’m going to rely heavily on logs. For example, if I want to perform cost optimization, I will use logging to determine if I’m using the right CPU, or if I am getting what I need out of my managed services. Since this information is crucial for decision making, I see logging as having an extremely high value in everything that is related to cloud management.

Alex: In connection to Kubernetes, it’s not a problem to implement logging from an early stage – you simply buy a service. I notice that it’s particularly important for the development stage, because if there isn’t some kind of order in the logs, then every programmer prints what he thinks he needs, and this leads to having too much information on hand. The logs become too big to sort through when you want to understand a specific problem.

Israel: Logging is of course, excellent, but you also need someone to look at logs. When it comes to security logs, knowing how to monitor and read them isn’t a trivial matter – you need someone with the right knowledge and the right capacity. This makes it a bit unrealistic for young start-ups to have someone in-house doing this work, and it becomes a perfect example of a service you should outsource.

For more information on production readiness and managing your product’s security and scalability with the cloud, see our extensive library of articles by 2bcloud experts, or contact us for a one-on-one assessment.