paint-brush
The Evolution of Cloud Native Productsby@David
296 reads

The Evolution of Cloud Native Products

by David SmookeJuly 10th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>Please welcome Iron.io CEO </em><a href="https://www.linkedin.com/in/dylanstamat/" target="_blank"><em>Dylan Stamat</em></a><em> to Hacker Noon! </em><a href="https://bit.ly/2NFDlXV" target="_blank"><em>Iron.io</em></a><em> is a cloud application services provider that eliminates the need to worry about infrastructure, and a marketplace partner of our past weekly sponsor, </em><a href="http://bit.ly/2LVXiI3" target="_blank"><em>Manifold.</em></a>

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - The Evolution of Cloud Native Products
David Smooke HackerNoon profile picture

Tech CEO Interview

Please welcome Iron.io CEO Dylan Stamat to Hacker Noon! Iron.io is a cloud application services provider that eliminates the need to worry about infrastructure, and a marketplace partner of our past weekly sponsor, Manifold.

Manifold is the marketplace for independent developer services. You can learn more about their partners by checking out this interview with JawsDB Founder John Willman and this interview with LogDNA Founder Chris Nguyen. For Hacker Noon readers, Manifold is offering $10 off any service with code HACKERNOON2018.

David: Let’s talk numbers, what is the scale of your business? And what metrics do you use to gauge company progress?

Dylan: Our metric for company progress is the growth of our customers that are actively using our products. When you provide cloud services, you’re operating in a landscape that didn’t exist 10 years ago. And in cloud specifically, you’ve got one major player that’s dominant and unafraid to eat its ecosystem. So what we’ve been focusing on is delivering long lasting value to those folks where our particular offer is a great enduring fit.

How has the technical infrastructure to rapid scaling evolved over the last 5 years?

Like many startups, our initial prototypes were in self-contained code we architected with centralized services and bottlenecks. As we’ve handled scale of 100MM requests/second bursts, we’ve had to remove those bottlenecks. You’ll see in our codebase similar architectural choices to what’s happening in most other distributed systems: leader election that moved from paxos to raft, a reduction of dependencies on underlying services that just don’t scale very well (sorry Mongo), etc. On a language level, we’ve moved from lightweight scripting in our earliest prototypes to Golang. Our latest products are being written and profiled in Rust and proving to be strong in their operational guarantees and performance.

Your flagship products are IronWorker and IronMQ. Could you break down how these products fit together, and usage numbers for each?

It’s funny, in the race to taking a cloud computing lens on every problem, it’s batch processing, a 50 year old challenge that we’re great at solving.

This shows itself in many, many diverse business opportunities: ETL, at-scale messaging, data consumption and aggregation. For instance, we being used for ad-hoc data transition services by one of the country’s largest telecom companies; and simultaneously we batch process IoT data from an extremely successful bar automation service. What all of these folks have in common is a need to massively scale out a worker pool to a varying influx of tasks. We started IronWorker around providing the best ad-hoc worker experience (and we still do!) but found that the queues available to run it (SQS/Rabbit/etc didn’t cut it) didn’t meet our needs, so we built IronMQ from scratch.

We want our products to be stable and scalable, but also extremely easy to use. If you want to use IronMQ for example, you don’t need to set up security groups, roles, network configuration endpoints, etc. You grab a client library (or use our API’s) in whatever language you’d like and start using it. There are some nice synergies between products as well. For example, IronMQ has a type of queue we call “Push Queues” which can fire off events when messages are received. One type of event is a direct hook into IronWorker, which means you can fire off workers based on message payloads. This cuts down a lot of the code you’d need to write to coordinate things. Another benefit is that we offer on-premise deployments… you’re not tied to a public cloud. You’re able to future-proof your choice in a way by minimizing lock-in. Just as an example, the operational expense of moving IronMQ to a different platform would be much, much lower than that of migrating your SQS implementation to Cloud Pub/Sub. No actual application code changes needed.

In May 2017, Xenon Ventures acquired Iron.io. Over the last year, how has the company evolved post acquisition? And does Iron.io fit into Xenon Ventures bigger vision?

Xenon was one of the first investors in Iron and our team founded an early cloud management platform called RightScale. So, we have an appetite for cloud services and understood the team and technology. What Xenon is able to do is treat cloud services as independent businesses that do not need to find a future acquirer to be cash flow positive and growing. It’s a bit weird to say this since you might think that every company wants to be able to survive without needing to raise more money or get acquired, but that’s what Xenon’s vision is for Iron. To be self-sustaining and under no pressures except to win customers and keep their business. Yes, we see lots of trends and cycles in cloud infrastructure, but we’re not so big that we need to be part of any bright and shiny framework in order to thrive. If you spoke to me two years ago you might wonder if we were going to support Meteor, now it’s probably whether we’re going to support a GraphQL interface :) The reality is we’re attacking a constant, plaguing business problem and it will appear in whatever greater movements are happening in the cloud.

I see you’re based in Las Vegas. What is the Las Vegas tech scene like? The Downtown Project has been something I’ve been following from afar. How does the tech community fit into to everything else that is happening in Vegas?

Vegas is awesome and downtown is amazing. You’ll often find me at The Laundry Room, Atomic Liquors, or Palomino.

Vegas is the antithesis to the bubbly feel of San Francisco. It’s an hour away, incredibly easy on the budget, and has a chance to become a second hub for Silicon Valley companies.

We hold meetups in San Francisco and, well, sometimes folks here might be a bit opinionated about the quality of the free pizza or even the free non-craft beer. It’s like Richie Rich took over the tech scene. Ironically, in the glitz and glamor of Vegas it’s the opposite. Hard working teams really standing for something by going against the grain. The focus is not on getting that $1000 Boosted Board or trying to rent in the city, but instead making real business impact and focusing on growth and customers. Yes, there’s downsides, but if you asked me where a startup with $1MM would get the most value, I’d say Vegas. Our building has a coworking space in it and you’d be amazed the companies that have a presence there.

Why did you decide to partner with Manifold?

We’ve actually had some past success in other marketplaces, so we started an initiative to seek out other marketplaces we may want to move into. When we ran across Manifold I was immediately interested. I really, really, like the fact that it’s platform agnostic. Like many engineers, I’m not a fan of coding myself *into* an individual platform. The integration was crazy easy and we were integrated, tested, and on the platform way faster than we originally planned for. Another benefit of Manifold is that we weren’t just dumped into the marketplace and left to wither. Their team is extremely customer centric, they have marketing strategies, and they know technology. It was definitely a perfect storm type of situation for us and they are an amazing team to work with.

Check out Iron.io on Manifold