Managed or Unmanaged or something in between?

As you build a product, offering, or a team, one of the implicit questions you must answer up-front is "how managed" you wish your offering to be. This question applies equally to you as a consumer who wishes to evaluate multiple offerings to see which makes more sense for you as a user.

In practice, you will never be on the completely managed or the completely un-managed side of things, but in some practical middle. Over the years, the trend has been to have more options available open up on the managed spectrum of offerings.

So what exactly does it mean for an offering to be "managed"?

Well, the "managed v/s un-managed" question is more of a conceptual one, but is best explained with a few concrete examples.

1. What is the difference between a managed v/s un-managed cloud offering?
2. What is the difference between managed and un-managed code?

In both of the examples above, the common theme is that a managed offering looks more like an end to end solution that solves a user scenario, whereas an un-managed offering is usually one of the many ingredients of an end to end solution to a user scenario. One can also very loosely compare the managed v/s unmanaged concept with framework v/s library offerings (see also this link for library v/s framework).

Just to make sure I am explaining the concept clearly, when I say that an offering is "managed" I mean that as far as the consumer of this offering is concerned, they do not need to manage its operations, and they can rely on it as a black box for the most part.

There are many levels of a managed offering one can find in practice

Managed v/s un-managed is not a binary state. i.e. there are many shades of managed-ness involved in practice. For example if you consider a typical cloud offering, here are some options:

1. Data Center space provided, and you need to bring your own machines, set them up, get power lines, network lines, set up cooling, etc... In the context of this discussion, we can consider this to be completely unmanaged.
2. Data Center space, power lines, network lines, cooling provided, but you need to bring your own machines, and maintenance staff, etc... This is slightly more managed than the previous offering.
3. Data Center space, power lines, network lines, cooling provided, machines, and personnel provided, but you need to manage the machines, software installation, monitoring, uptime, etc... This is slightly more managed than the previous offering.
4. All of the above plus an installed OS and management tooling provided, but you need to install and manage application software, etc... This is even more managed than the previous offering.
5. All of the above plus application software, monitoring/management tooling/interfaces provided, and then only thing you need to do as a user is provide a single function (think AWS lambda) that encodes your specific business logic. Everything else is taken care of for you. In the context of this discussion, we can consider this to be completely managed.

Pros and Cons of managed v/s un-managed setups

The pros and cons of managed v/s un-managed setups can be thought of from 2 different perspectives; i.e. from the point of view of the provider, and from the point of view of the consumer.

Consumer side view of a managed v/s un-managed offering

• Pros of managed
• Easier to set up and get started. Typically, out of the box (canned) solution works for most "common" use-cases.
• No hassle of maintaining or managing anything. Pay as you go.
• Easy to scale up (typically) by paying more. No (or very little) lag time between increased demand for your offering and ability to scale up. You don't need to be super buttoned up with planning and capacity projections in so far as the specific offering you are relying on is concerned.
• Allows you to focus on the unique value that you are providing to your customers. For example, as someone who runs a bakery, having Shopify manage the app, payments, delivery, etc... is super awesome.
• No need to worry about common concerns that are addressed by the provider. For example, in the context of a web-service being provided, the customer need not worry about kernel upgrades, web-server updates, security patches, etc...
• Cons of managed
• May cost more overall (TCO) compared to if you were to manage everything yourself. This typically becomes relevant only if you reach a certain scale.
• Managed offering may have severe limitations that limit your ability to scale up or scale out to more user scenarios. This is a quality aspect, and if you have a good relationship with the provider of the managed offering, you could work something out. This also relies on the vision and relative priorities of the managed solution provider.
• The only tunables are the ones that the managed offering provider offers. For example, if you are using Amazon AWS Lambda, it may be hard or impossible to configure low level kernel parameters or select a specific version of a language runtime. You are limited to using what is provided, and can't customize things beyond a point.
• There is a risk of getting too tightly coupled with the offering. If the offering isn't implementing an open specification, there is a risk of vendor lock-in. If the vendor decides to increase rates (for a SaaS model) or drop support (for a more traditional offering), then the cost to move to a different vendor may be cripplingly significant depending on how broad/deep the dependency is.

Provider side view of a managed v/s un-managed offering

• Pros of managed
• A managed offering means that the provider has greater flexibility over the implementation, and can keep changing the underlying implementation (and reaping cost savings and benefits as a result) since customer doesn't depend on the details of the implementation. A great example of this being leveraged is in the various types of JVMs available, each having its own advantages and disadvantages. In the case of Shopify for example, they can change shipping providers without the customer having to worry too much. In case of AWS, they can keep charging the same amount per GB for storage, but negotiate better costs with their supplier and not pass that on to their customers.
• The abstraction layer between the customer and the infrastructure reduces overall maintenance and upgrade costs since the provider has complete control over the offering. This is beneficial for the customer as well since they can be on the latest and greatest offering. For example, a cloud offering is much easier to manager/upgrade compared to an on-premise offering. For example, how often have you (as a customer) worried about an update to the gmail backend?
• Cons of managed
• Easy to provide an offering that works for small (or medium) consumers, but challenges become increasingly hard to scale up to large and extra-large scale customers. For example, not many cloud providers can scale-up to the level that AWS can. CodeIgniter (a very popular PHP application development framework) works really well for small/medium size apps, but not necessarily for large scale ones. The level of architectural and design thinking needed to scale up is a few orders of magnitude more to go from medium to large than it is to go from small to medium. Most managed offering providers fail or crumble because they can't make this leap.
• Additional considerations of managed
• Requires a lot of resources and up-front thought to provide. Need to understand numerous use-cases before deciding the platform to provide that is generic enough, and yet absorbs most of the common pain-points of customers.
• Need to plan to grow/hire a significant workforce (various disciplines) to support a managed offering. For example, AWS would need to hire not only engineers, but also sales reps, a customer success team, maintain detailed documentation (technical writers), etc...
• As a provider, you need to be extremely careful about the published API and contract that you are exposing. For example, if you run a service like AWS lambda, and you expose a Java interface, and the customer takes a hard dependence on a specific behavior of a specific Java runtime version, then you can't effectively upgrade the Java runtime without working closely with the affected customers or breaking their application (and hence losing their business and tarnishing your own image).