SaaS & Web Operations: Why I love this job…
SaaS & Web Operations: Why I love this job…
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
I have been working in SaaS organizations now for about 5 years. When I first made this move I was convinced this is where things were headed and now it has become plainly obvious that this is where virtually everything is headed. Just about everything you do is on the web now and all those companies have infrastructure & Operations teams behind them. I love working in SaaS companies for a number of reasons – but not everyone seems to understand why SaaS is so great. It has some to do with the customer & the quality of the product you can deliver – but it also has a lot to do with the capabilities you have as a SaaS organization. Some companies leverage those abilities to make their product better – some don’t. This difference, to me, is a big differentiator between great SaaS companies and the rest.
So why do I love SaaS so much? Take a look at this:
That’s from a web page displaying the availability for a particular service. Can you tell me how this was generated?
Unless you know what this page is & unless you work for the company who produced it (or know the right person who does) then I strongly suspect you have no way of knowing how this was generated. It could be automatically updated based on complex calculations across a datacenter of thousands of systems observing millions of metrics and distilling all that down to a single number that gets placed here through a batch auto-update process each day or week.
It could also be some guy who is entering data into a spreadsheet each week & spends hours and hours coming up with this number – going in and editing the html to show the appropriate value.
Do both approaches have value for the customer? If that number is relevant and accurate – yes, they do.
This is why I love SaaS. You’re confused now right?
SaaS means Flexibility, Insight and Agility (if you are doing it right)
My point about the statistic above is that it doesn’t matter how the number was generated to the consumer – it just matters that it’s what they expected to get. There are a million ways to deliver on that expectation and the beauty of SaaS (as well as the Art) is that you, as the provider, get to choose how this is done to best meet the needs of your customers & your business.
I’ll take a more concrete example. In a past life I worked for a company that wanted to provide Windows Streaming Video to Windows Mobile devices. They had some content agreements & agreements with carriers to provide this service by a given date – that date was pretty darn aggressive (aren’t they always?). There wasn’t time to build the encoding infrastructure & get it all working by the date – so they opted for a hack.
They already had the ability to create RTSP streams, and they had windows streaming servers that could deliver the WMV stream to phones – what was missing was the conversion from RTSP to WMV. The solution was to install video cards on the Windows encoders, connect to them via an IP-KVM, and run two applications on the desktop – Quicktime to display an RTSP stream and a screen-scraping program to grab that output and encode it to WMV.
This is easily one of the biggest hacks I’ve ever seen to deliver a service – but it worked.
After the service was running, time was spent to build the encoding software & it was deployed a few months after the service launched. But the important part is that the service launched, and they swapped out the backend without anyone being the wiser.
Flexibility is having options. Sometimes those options aren’t pretty – but you still have the option to choose what is best for your business.
Amazon – that name for most folks is synonymous with shopping. If you are a nerd like me, it’s synonymous with utility computing. Either way, Amazon has built a massive business around selling people things they want. Amazon didn’t get there by guessing at what people wanted – they got there by gathering data about buyers habits and tuning and tweaking and experimenting with different ways of changing the shopping experience to try to maximize the chances that you’ll buy something. Every click, every mouseover, every move you make on the Amazon site – I’m certain – is collected, analyzed, and trended to identify what is making you do what you do. Amazon has massively disrupted the traditional model of shopping by analyzing, understanding, and pivoting to meet the silent demands of consumers. You probably don’t even realize what you are telling Amazon when you shop – they likely know more about why you do what you do than you do.
All SaaS organizations can do this – and some do but many do not. There are massive amounts of data that can be gathered and understood through every transaction your customer makes on your site. This data, combined with experimentation with different changes, should guide every decision the business makes. It’s not the only metric – but it’s a massively important one and it’s quantitative vs. qualitative – it’s data driven.
This goes beyond just understanding your customers behavior – it also applies to understanding your system behavior
- Tracking and trending response times, failure rates, client response times, end to end response times (with each transaction type involved measured independently), request types, and whatever else you can track.
- Gathering aggregate data (counters) as well as per request metrics to help identify big trends on average – as well as detecting outliers which are more subtle.
- Being able to replay a sequence of events a customer performed before they hit the “Oops!” page on your site.
- Correlating system events (software releases, for example) to these trends to identify changes in behavior in response to an event.
The list goes on… If you aren’t constantly striving to improve your visibility into customer behavior, customer experience and system behavior you are missing out on a massive advantage SaaS has over traditional software & someone else is going to put you out of business. Make no mistake, the big SaaS companies got where they are largely because they did this analysis and understood their surroundings. Without that data you are just trusting your gut, which in the best possible scenario is luck.
Agile methodologies and SaaS go pretty well together – but the name “Agile” refers to a capability that those methods provide – the ability to move & adjust quickly. Traditional software doesn’t have to change quickly and in many environments change is viewed as a bad thing – it introduces risk and creates uncertainty. In a website trying to gain customers & build new features to compete, the ability to move fast outweighs the risk of change. In a hospital where lives are at stake the equation is reversed.
Most SaaS businesses are more like the website – they are trying to build a customer base or keep an existing base satisfied. After all, customers take a risk too when they go with SaaS – they are trusting their data to the company and they are trusting that the company will manage the service well, stay in business, and keep the service that the customer relies on available. Customers take this risk because they want the benefits of SaaS for them:
- No infrastructure to maintain
- New features without any real work to upgrade their software
- Availability that is otherwise costly to provide in-house
- Scalability is someone elses problem
Putting the Insight and Flexibility together should give you some well informed options for how to grow your system and satisfy your customers. What it will also do is give you multiple choices for virtually every decision you make. There will *always* be more than one way to skin the cat – usually more than three ways infact. Selecting the right way is sometimes apparent when analyzing the data but other times you have to experiment – this is where agility comes in.
My present company deploys code weekly. Every week the work of the developers for that week goes into production – finished or not. “Finished or not?!? What?”. Yes, we deploy incomplete features to production – and we leverage feature toggles to enable those features when they are ready. Why do we do this? Because we can deliver incremental value to the customer every week. Every single week (except when things don’t go quite right) new code is deployed, bugs are fixed, and very often new capabilities are turned on.
If something doesn’t work – we can change it next week. If it’s really important, we can patch it mid-week. The risk of deploying new changes is low because we do it all the time & each week the incremental change is minimal. If we want to change course, we incrementally get new code out there – testing it as we go – until we’re ready to expose that change to the customer. If the new stuff doesn’t work we are just a feature toggle away from switching it back to the old code.
Continuous Flow is how things are getting done, moving things into production as frequently as possible. Amazon deploys to production about every 11 seconds. That is about as continuous as it gets – and that probably isn’t often enough in the minds of some folks at Amazon. This means they deploy over 1000 times per hour. This also means that if one change causes a problem the fix can be deployed damn fast.
So why do I like this all so much?
Because it means that work I do delivers value quick. I don’t typically work on projects for months and months and finally deploy it to find out if there’s value. You add value incrementally over time, you realize the value quickly & increase that value over time. You also work as one big team performing that delicate balancing act that is the Art of Moving Fast, the balance between taking risks & minimizing problems. There is not one recipe for how to make this work and while there are some very large players out there doing a very good job at this – their expertise is largely considered their property and they don’t share it. So as a community we have to share what we know to continue improving our collective knowledge about what works, what doesn’t, and what should work.
The world of Web Operations is still a bit of Wild West, but there are are pockets of civilization forming. There’s still a huge need for individuals who understand how things should work & want to make change for the better in organizations who don’t yet “get it”. Over time those organizations will go away, only the strong will survive, and natural selection will do what it always has and weed out the weak.
The strong will be those who not only have a compelling product, but who understand what it takes to deliver that product to consumers and meet the ever-changing demands of the world today.
Opinions expressed by DZone contributors are their own.