DevOps is the philosophy informing how a technology organization embeds itself in a business to the benefit of that business.
W2O is a leader in social data analysis, so we, the technology team, must first innovate then develop products for our customers that we can delivery repeatably, reliably and successfully.
Scaling a System
For a system to be reliable it must serve a number of customers without slowing down or crashing.
Typical conversations around scale are about the amount of stress a number of users puts on the system. Remember the last time Twitter crashed when some topic began to trend? This was a disaster because it meant that Twitter failed when most people were excited and looking. Because all users share the same infrastructure at Twitter, once the system tips over, all users are disappointed.
Viewed from a customer satisfaction perspective: A tenant threw a party in Twitter’s apartment building and nobody could enjoy their evening.
Twitter is a B2C system. In the B2B world, stress on a system is rarely measured as a function of the number of users. Data volumes and analytic processing capability are the primary factors. One user will create stress on a system by performing complex analysis on a large batch of data. Shouldn’t the architecture of a B2B system have different considerations?
Innovating for S2aaS
When innovating, which is important:
- Develop features to solve business problems?
- Develop a user management system?
During the innovation phase, we can usually ignore user management and start with a solution to the business problem. We are focused on adding features that demonstrate the existence of a market. Features define that market. Wrestling with the overhead of keeping users silo-ed is not a required feature. In the B2Beginning, there is only one customer.
When innovating, Developers deliver features and Business gains measured insight into customer requirements because customers are using the system. This is a core point made by Eric Ries, in The Lean Startup.
Traditionally a second customer means Developers decide it is a requirement to add the new customer on the same infrastructure while the software keeps them from seeing each other’s activity. This is known as a multi-tenant system–like the Twitter apartment building.
“Features” like the user management system slow the pace of innovation. Every new feature must also account for keeping users silo-ed. Leadership becomes frustrated because the sales team has proven the product concept by reenforcing that a market exists with this second sale. The market is responding to us! We slow down our most fundamental response: more features.
Why do we allow this to happen? Developers and Operations staff traditionally have an apartment mentality. This is what drives innovation in the technologies they work with every day. It turns a business problem into an engineering problem.
Basic B2B Software Economics
Consider who is paying for the system and their expectations. When dealing with the consumer internet, the apartment model is acceptable. If a few people get wild, we wait for the landlord to restore order. Business customers don’t want to know their neighbors. They want their own single-tenant dwelling–a mansion with a grounds crew and service staff. They want service with their SaaS (S2aaS).
In a B2B engagement, the customer pays a recurring monthly fee. Recurring revenue is a key performance indicator for most B2B vendors. It allows better terms when obtaining credit or attracting investors. Key in setting price for such a software system is the market’s perception of value. Eliyahu Goldratt makes for avoiding pricing a product based solely on cost in his novel, It’s not Luck.
Engineers often make the case that building separate infrastructure for each customer (i.e. their own house) is ineffective. They do not account for the realities of the B2B market:
- The customer is paying $1000s per month. Adding $100 per month to the cost is trivial.
- Developer time is precious
- Customers buy because the features of the product meet their needs
- Customers buy because the features of a new product demonstrate needs they did not know they had.
- Customers do not buy because of user management.
- Customers do not buy because of the latest and greatest technology
An apartment building must be built of sturdier stuff. It requires more maintenance. It has common areas and a staff not found in a single-tenant dwelling. Apartment dwellers have lower expectations and spend less money on housing.
In a software system, these considerations are expressed as a user management system. Because everyone’s data is housed in the same infrastructure, heavy duty technology such as Hadoop or Cassandra become necessary. These systems require expensive infrastructure, expensive Operations personnel and expensive support contracts to run them.
More Engineers Providing More Value
Instead of an apartment building, consider leasing single-family dwellings to B2B customers. This moves the burden of scale from Development to Operations. A new sale means launching a new system. The Operations team works to make this launch repeatable.
In addition to not developing unnecessary features, the problem of scale is per customer. This means that, during innovation, scale is unlikely to be a issue in need of engineering time. We need only be able to make the manison big enough for one customer. Not an apartment big enough for all customers. A much simpler engineering problem, thus more time to focus on the business problem.
The Development team now has more time for features while Operations innovates on better launches and maintenance of systems. Development is not worried about a big party burning down the apartment. They are concerned with adding better features to the house. More of the right features sells more houses. Couple this with failing fast, and the product team is able to run experiments and determine which features matter most.
Operations is now contributing to revenue generation rather than just cost management.
Scaling B2B Sales
The confidence of a sales force in selling B2B to customers cannot be under estimated.
When a tenant in an apartment building throws a huge party, nobody sleeps. If a party burns down the apartment all the tenants are looking for a new place to live. When a party is thrown at the mansion down the road nobody cares. If the party burns down the mansion, only that customer is homeless.
In a failure situation, only one customer is affected. Confidence of the sales team remains high and keeps the pipeline full. Stress on Customer Service, Development and Operations teams are much lower. Lower stress means better observation, orientation, decisions and actions in a crisis.
B2B Market Outliers
If a customer grows their data set or analytics needs beyond the current capability of the system, the same arguments hold. The problem of scale is unique to only that customer. All other customers are snug in their mansions unaffected and unaware of problems.
W2O now has an opportunity to innovate rather than react. First, a decision can be made by the business around the value of servicing such a large client. Maybe this is not a good segment of the market for us to be in. In this case, we can work closely with the customer to help them choose a new vendor.
If, however, we decide re-engineering the system is the best path, sales of the existing system continue undisturbed with the caveat to pay extra attention to the size of the customers needs. Engineering and Sales are now partners in success.
In the single-tenant world
- The Operations team does not have to run exotic technology at scale.
- Developers use common patterns practices that have over a decade of success behind them.
- Risk to all customers and to W2O is better managed.
- More value is provided with the same size engineering team.
The basic assumption of a single-tenant system is that it can be created on demand. The system can be launched with the push of a button, fully configured and operational and regardless of the state of any other customers system. This means the Operations team has a vital role to play in innovation. The entire technolgoy team is moving toward value to the business. We are now operating under the DevOps philosophy.
What is missing from this conversation is Quality. Quality is what we will approach in the next DevOps Digest.