You are here

Cloud Services

Interview with Zymr

Clutch spoke with Haresh Kumbhani, the CEO & Founder of Zymr, about the options and processes for cloud infrastructure implementation – an important consideration for anyone considering operations in the cloud.

Learn more about Zymr on their Clutch profile or at


Introduce your business and what you do there.

My name is Haresh Kumbhani and I am the CEO of Zymr, a cloud software product development company. My own background is 30+ years of experience working in enterprise software and solutions. I have a master’s in computer science from NYU, as well as an MBA from Santa Clara University. I am a serial entrepreneur and have worked in the Silicon Valley landscape for the last 30 years.

We partner with many cutting-edge innovators in the cloud space. Zymr is a four-year-old company with a team of about 150 engineers. We’re pushing the cloud envelope.

Which cloud platforms are you most familiar with?

We describe ourselves as a full-stack cloud solutions developer. In this space, we focus on five elements, including building soup-to-nuts cloud applications within the X-as-a-Service model (Software-as-a-Service, Security-as-a-Service, Network-as-a-Service, and so on).

We are also very good with enterprise mobility and with the whole idea of trying to develop something which enables users of these services to connect to complex backend systems through mobile and web UX/UI [user experience/user interface] environments.

The third piece of the puzzle is cloud orchestration, namely enabling full service lifecycle management, from multitenancy to onboarding subscribers, doing analytics in the background, connecting cloud services to payment gateways and any other external systems, including extensions of legacy applications, and doing all of this in a controlled and continuous way, providing delivery and visibility into what’s going on within the service once it’s launched.

The fourth piece of the puzzle is about cloud security. Anytime we get into the cloud arena, thinking about security from the ground up is quite critical. The top processes at Zymr require that security be done at the microservices level and all the way down to component level. This is where we bring the expertise of understanding the need for security, which can involve not only HIPAA [Health Insurance Portability and Accountability Act] compliance, but it can also be common sense segregation of sensitive information from the rest of the database. We partner with innovators in order to think through the security puzzle, focusing on network and data security. While we have helped clients build award-winning cybersecurity products, we do not have deep expertise in digital forensics and rely on client specifications for that aspect.


The last piece is our thorough experience in cloud infrastructure. Within this, we have compute storage and networking, as well as Wi-Fi and network technology knowledge in general, which lends us to helping customers in utilizing the solution they’re trying to build, either for on-premises enterprise environments, cloud, or hybrid. Within the cloud infrastructure, having a sound understanding of compute storage and networking enables us to leverage ready Infrastructure-as-a-Service features from Amazon, Google, or Microsoft cloud, for our clients’ benefit. We have to be cognizant of what should be in the public cloud, versus what should be run on-premises, how the data should be moved back and forth, how it’s secured, and many other subtleties in ensuring that we’re doing the right kind of partitioning of the problem. Zymr is working with venture funded startups, as an innovation leader in these areas.


Could you talk a bit about what an initial client implementation and migration looks like?

One of the things which Zymr does well is to help companies develop a software strategy, and based on it, the structure needed for the implementation. At all points in time, care must be taken to not over engineer solutions. When customers come back and request either going through a digital transformation journey or are trying to build the next X-as-a-Service, then Zymr can be a good partner to have, primarily because we have past experience working with 50 or 60 product development cycles.

An engagement starts by really understanding the goals of the client and their requirements, which may be organized in epics and user stories. We come in and truly immerse ourselves in the ontology side of the puzzle. Ontology is a loaded word, but what it means to us is that we have to dissect the domain in which the companies are trying to build something. Whether it’s a FinTech or a HealthTech solution, we need to understand what it is they’re trying to build, as well as the personas of the solution’s users. We have to determine whether it will be consumed by enterprise users, consumers, administrators, or whoever else they may be. The last part is thinking about the organizational structure of the project, in which nothing should be thrown in without thinking through the vertical slicing of the puzzle. It’s better to build a product in vertical slices than horizontal ones.

Startups will typically start building a platform, and then look for a problem to solve through it. We advise clients to really think from the use case, from top-down and build vertical slices of the platform. From our experience with open source tech, selecting curated technologies involves hundreds and hundreds of products to choose from, and assembling the right pieces of the puzzle, whether those are Apache Spark, Java, Python, PHP, or anything else.

Vertical slicing is one of the elements which people don’t really understand, and it’s something we really bring to the forefront. Having understood the problem domain and the use cases, and having sliced the puzzle into vertical pieces, we will then look at selecting the technology stack itself. There are two parts to this argument. Firstly, we have to be very deliberate in understanding if the customer already has their own selected stack in play. They may have their own engineering team, which has chosen X, Y, and Z, so we try to accommodate any existing work, whether it’s using the Microsoft .NET stack, Java, and so on. If nothing is in place, we can do what I call “spikes”. A spike is a rapid prototyping of a puzzle by which we do a technology evaluation, select stacks, and lay the foundation for the platform itself.

The last part of the puzzle is to think about whether to use Amazon, Google, or Microsoft. The customer could prefer Azure, or AWS [Amazon Web Services], but vendor lock-in is something to consider. If we get into the Microsoft ecosystem or the Amazon one, we’ll be stuck really hard. We do ask clients if they’re sure of their choices and ensure that there is a right level of leverage to be had from the cloud provider, but that they don’t get too deep into it, too early. They should wait until they know where their market and customers are going. We’ve had cases in which a customer leveraged AWS or Azure and then realized that, when they wanted to sell the product, the enterprise wanted to use it in-house on VMWare. A part of the evaluation is thinking through not only the technology stack for the implementation but also where the service will be delivered. Zymr is very good at giving the pros and cons for this choice.


What are some unique strengths for each platform?

The king of the hill is Amazon, and the amazing thing about them is that they’ve adopted a Steve Jobs kind of selling pitch. They unveil one new thing at the very end of each presentation. It looks amazing. I’ve been tracking AWS since its inception, and we’ve been playing with cloud technology from our start.

If someone is trying to build a solution for the healthcare industry, for example, data privacy becomes a huge issue. They may want to deploy the service globally, go from the US to Canada, Europe, and to the Far East, but each of the local board members wants to have data locality. It becomes important to know if Microsoft or Amazon have a presence in those regions and if they have the right kind of datacenter to ensure that the information will not leave those localities. It depends on the needs of people from these highly-regulated industries. All three companies have a global presence at an almost equal level, but it’s still a point of consideration.

The second part of the puzzle is about the ready services available from each cloud provider. Amazon has RDS [Relational Database Service], through which one can spin-up a MySQL server, for example. The problem with this tool is that people won’t know exactly where their data is, even though they own the implementation. It can sometimes even be more efficient to create your own virtual machine and install your own database. These trade-offs have to be thought through carefully.

It makes sense to use Domain Name Servers or anything to do with content caching. The content distribution network infrastructure provided by each of the cloud vendors is extremely powerful, and it’s perfectly fine to use, but when it comes to the guts of the systems and using the providers’ notification systems, they may sound cool, but they do create a lock-in.

There are many workflow-based services through which users can trigger actions on their own system or outside of it. They are vendor locked, so deciding upon them needs to be done carefully. There are alternatives to them outside of vendor-provided services. We can build our own workflow engine, and retain control. All of this should be done while thinking about cloud portability. Make sure that the solution is easily movable from Amazon, to Azure, and to Google. It’s not easy to do, but it’s definitely possible to plan for those contingencies.

Do you find cloud as being the more cost-effective option, or does it open the door for more IT spending, compared to legacy options?

A very interesting development, which has occurred in the last two or three days, has been from Michael Dell. He has stated that, for enterprises, using the cloud is not as cheap as we think. Many clients initially find it cool to spin up multiple virtual machines, only to be shocked when the bills start coming in. There is a price to be paid for auto-scaling, and it implies cloud bursting. The price goes up along with virtual machines, or it could be that clients are paying for services they’re not really using. There are many complex calculations to make, and AWS, Azure, and Google have done a number on most people. They get people hooked and provide extremely complex planners for the cloud, so much so that people need external software which will monitor services and optimize costs.

Coming back to Michael Dell, he has proposed utilizing Dell data center hardware on a pay-per-use basis. Suddenly, enterprises don’t have to buy multimillion dollar hardware infrastructure and put it in private data centers. Dell is willing to lease that infrastructure based on use. In other words, they are trying to compete with the cloud from a pricing standpoint. I don’t know what that will lead to, but I find it to be a very shrewd and smart strategy from Dell and the likes of Dell, in order to really win in this cloud war.

The main thing which most companies have to deal with, if they already have data centers and resources, is determining whether or not it's economical to continue using them while also thinking about cloud-centric ways of deploying services.

The key thing in terms of data security is that cloud providers definitely provide a much more robust infrastructure level solution. Anything above the infrastructure needs to be taken care of by the companies deploying services on the cloud, in terms of access privileges, data-retention policies, and so on. The same level of data security may not be achievable on a company’s own servers.

Cost is always measured in terms of TCO [total cost of ownership]. When it comes to TCO, we really need to think about the cost of a potential security breach. That can damage someone’s reputation, become a headache for compliance reasons, and so on. For a startup, it makes no sense to choose anything other than the cloud since they don’t have any legacy components to deal with. For a non-startup trying to undergo a digital transformation and create a cloud hybrid, the math becomes a bit more complex. All cloud providers are in a constant pricing war, and they will suck up money through esoteric things like elastic IPs.


We have 5 additional questions. For each of these, we ask that you rate the providers on a scale of 1 to 5, with 5 being the best score.
How would you rate them for functionality and available features?

AWS – 5
Azure – 4
Google – 3 – They still have many services labeled as beta, but someone from the company said that they will surely win over Amazon over the next 10 years.

How would you rate each provider for ease of use and ease of implementation?

AWS – 4
Azure – 4
Google – 3

How would you rate them for support, as in the response of their team, and the helpfulness of available resources online?

AWS – 4 – They have the best support.
Azure – 3
Google – 2 – We’ve had real difficulties with them over the few implementations we’ve had. There was hardly a lot of help that we could receive.

How likely are you to recommend each provider to a friend or colleague?

AWS – 4 – They will always be a top recommendation for us.
Google – 3
Azure – 3

How would you rate them for overall satisfaction with the platforms?

AWS – 5
Azure – 4
Google – 3

Expert quote
"The last part of the puzzle is to think about whether to use Amazon, Google, or Microsoft. The customer could prefer Azure, or AWS [Amazon Web Services], but vendor lock-in is something to consider. If we get into the Microsoft ecosystem or the Amazon one, we’ll be stuck really hard. We do ask clients if they’re sure of their choices and ensure that there is a right level of leverage to be had from the cloud provider, but that they don’t get too deep into it, too early. They should wait until they know where their market and customers are going."