Dion Almaer

Software, Development, Products

The difference between Platforms and Ecosystems

tl;dr: “What’s the difference between a platform and an ecosystem?” This simple question resulted in an ecosystem strategy to connect sub-ecosystems that work on the Web. What if we lean in and deeply connect our tools, services, frameworks, and platforms….. and align on the right incentives for a healthy web?

I work in a product area of Google that is called Platforms and Ecosystems, and I sometimes reflect on the question “what’s the difference between a platform and an ecosystem?”

There are many, but I have found myself diving into the differences in complexity of a rich ecosystem.

With platforms we often think in layers, each layer building on each other, and the interfaces mostly being at the boundaries. This is a nice abstraction when done right, as it isn’t leaking all over the place.

The layers view of a platform

An ecosystem often forms on top of a platform, or if it gets connected enough, you get combinations. Sub-ecosystems form that have their own fractal view of the world, and they may connect with multiple technical platforms (e.g. the React ecosystem touching Web, iOS, Android, Desktop, ….).

The Web is complex enough that it is one of the canonical examples of an ecosystem that has many sub-ecosystems. You can even slice “the web” itself into pieces including the technical client platform that is embedded in almost every native platform there is (WebView anyone?) as well as the connected open Web, where many technical stacks are available to run as well.

A week ago, I had the pleasure of spending some time with representatives from major global CMSes, and they are a fantastic example of sub-ecosystems.

We spoke of ecosystem loops, and how an ecosystem has so many more connection points that are not restricted to layers, and are multi-directional.

These connection points, when strong, can enable a healthy web ecosystem. This realization has changed the way that we work, thinking about we can truly enable healthy connections.

Foundationally, we obviously want to build web platform APIs that work for as many ecosystems as possible, whilst also push the web. We also work to build clear guidance on web.dev that helps developers understand what is possible on the web across key pillars and principles. We want to deliver new and better tools that help you create, debug, and deliver actionable insights to you (e.g. DevTools, Lighthouse, CrUX).

Speak the right language

Lighthouse Stack Packs can speak your language

One of the problems we see, is that there is often an impedance mismatch between the layer of abstraction that a developer uses (e.g. using a particular framework, set of libraries, or backend infra) and the feedback that tools and services surface.

We are on a journey across our portfolio to fix this, and the best example is probably Lighthouse:

  • Lighthouse plugins allow you to build on the platform to offer your own audits and rulesets, enabling you to enforce you own criteria or requirements. For example, a framework may have important linting tests, or an ecommerce platform may have retail oriented audits.
  • Lighthouse Stackpacks bring an understanding of the ecosystem into the existing core rules. Don’t give generic guidance on next generation images when you could give custom guidance for particular plugins or point the developer to a setting in the admin console.

Elsewhere we are thinking of similar evolutions:

  • web.dev offers framework specific guidance, but what if the base guidance changed based on your needs?
  • There are many Chrome extensions for developers which extend DevTools, but what if there was a strong plugin API where knowledge can be brought to the core tools?

I am excited to work with the ecosystem to enable this kind of intelligence for our collective developers.

Show me the incentives!

We can make life much better for developers, but we have also learned that this isn’t enough to fully elevate the web together.

We want to see the flywheel moving nicely on the above ecosystem loops, with users engaging with high quality content from developers and their sites and platforms.

As platforms, how do we enable this outcome? It’s hard, but we have learned a lot from the work that the ecosystem did to move to HTTPS.

Moar TLS!

It may be hard to think back to the days when HTTPS wasn’t the norm, and only 30% of traffic was secured. How could we make it the vast majority? I remember hearing thought such as: “it can’t be done!”, “people just don’t actually care enough!”, “it’s too hard!”

In retrospect, it’s interesting to reflect on the parts and pieces that I think collectively drove things forward:

#1 Knowledge and Insights
There was a lot of content on *why* this is important, and *how* to do it. I remember it being really quite hard to do, and also waking up in a sweat on a couple of occasions with my brain racing: “did my certificate expire?“

#2 Tooling
The ecosystem jumped in to help make it MUCH easier. LetsEncrypt changed the game, and servers and hosts jumped in too.

#3 Demand
Now it’s easier, and it’s the right thing to do, but companies have huge backlogs. How do we make “the right thing to do” blindingly aligned to users and the company?

We need the right incentives, and this was the final puzzle piece. How do we reward developers that do the right thing? Some examples here are:

  • Browser UI surfacing quality: At first browsers changed their UI to highlight the good (e.g. showcase “secure”), and then…. over time…. deliberately…. switch to the point where the default is secure and we highlight the insecure
  • HTTPS required for API usage: WIth Service Workers, and powerful capabilities such as those being worked on via Project Fugu we need to make sure that we aren’t setting users up for attacks. This keeps our users secure, and also incentivizes developers to move to HTTPS to gain access to said APIs.
  • Acquisition: highly quality content is better for our users, so we want to make sure that Google Search is driving engagement to that content. When HTTP was added as a ranking factor we noticed an increase in adoption.
    It has been great to see the sum of the parts add up to the great adoption of HTTPS and we continue to push.

Moar Incentives!

How do we learn from HTTPS and bring this to the other areas of quality such as performance?

We will make sure that:

  • We will be clear about the metrics that we think represent quality
  • We will surface data and insights for developers and decision makers across our suite of products, and accessible for third party tooling solutions
  • We are very deliberate in carrots and sticks so everyone has time to plan
  • We will work with the sub-ecosystems so we can align on everything above so we row in the same direction. For example, if you are an established CMS provider, it isn’t solely important to track how many themes and plugins you have in your marketplace, but also note the quality of the output and how you can use said marketplace to share the same incentives (surfacing the right metrics etc).

How can we build connections that will strengthen us all? Do you see anything we should be doing? I am all ears.

The Order of the JSON

https://twitter.com/therealfitz/status/1161349619659530242?s=21

When I read Fitz’ tweet about ordered JSON my body shuddered, as my brain was flooded with a past experience that taught me a frightening lesson on technology being used by non-technical companies.

It was a moment that had me wonder:

  • How does world not break due to technology more often
  • How much time and money is wasted due to some ignorance at some part of the development cycle?

Ok, here goes. My frightening tale around the order of the JSON. I was working on a project for a large Fortune 500 (I will protect the name of the company to protect the innocent!).

The project at hand required integrating a modern front end (mobile apps and web) with a legacy system. This isn’t legacy in a “the engineering team really wants to rewrite it in the new shiny”, but in a “there is COBOL running back there somewhere isn’t there” kinda way.

Much of the system was so old that it was hard to find anyone who knew how it actually worked, and it’s maintenance had been outsourced to some of the typical IT outsourcing companies of the time.

At first all was well. We had created mock services that spoke the protocol and we were building against it. We were dealing with pretty simple REST calls with JSON, so it wasn’t like we were all SOAP-y.

We wanted to integrate with the real systems as soon as they were ready of course, and that’s when it got fun. I remember the first time we spoke to the system an got a terse error message:

ERROR 1000294

That was it. No more info. We asked the service folks for more context, and *two weeks later* we were told “Oh, the JSON payload that you sent us was in the wrong order“.

Huh? Why would you care what order we were sending the name value pairs for this?

We asked if they could fix this and be more flexible. They said they would get back to us.

It turned out their did a “LOE analysis” (level of effort, in case you haven’t had the privilege), and came back to tell us that they would fix it, but it would take 9 people 6 months to do complete. With a straight face. In a way that signalled that this is the cost of doing business and it happens all the time.

We couldn’t wait that long, and we thought about creating a custom emitter that would indeed order the JSON. We wouldn’t want to do it on the client, as what if something changed? We didn’t have faith that this “order” would be set in stone forever.

Ok, let’s handle it on the server then…. and have continuous testing to make sure that if anything changed we would know right away. Not the end of the world I guess.
But it still didn’t feel right. I got on a plane to visit the site where this was all going down.

https://twitter.com/sempf/status/514473420277694465

I mentioned that it was hard to find people who knew how these systems worked. I have previously mentioned how QA engineers are underrated and they came to my aide again here. I hunted down the QA lead and he took me on a tour of how he tests the systems.

I got to learn that we were talking to a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.

He was showing me the DataPower GUI, and let me play around with it. After awhile of drilling around and going through settings I got to a hidden advanced setting that was a checkbox asking:

Validate order of JSON? [X]

I unchecked it. Ran a client to post the JSON to that instance. It worked just fine.

And, then I sat back and contemplated how this type of event was probably occurring daily, all over the world, and some consulting companies were getting millions of dollars.

Finally, I was so curious about where the root of this came from, and did a search for ordered JSON and ended up on this IBM javadoc.

Of course! I am sure you have never run into scenarios like this in you time in tech, have you?

Does mobile documentation matter for developers?

Developers code on their laptops, normally docked with their mechanical keyboards and monitors, right?

As such, when it comes to developer documentation, you don’t need to be responsive, and can focus on a desktop-only set of docs.

I have heard this sentiment many times, and at first blush it makes some sense. For all the talk of mobile eating the world, a lot of the business end of things happens on the desktop Web.

Once you have desktop docs going, you look at your stats and see that you were right! A fraction of traffic is coming from mobile! Glad you didn’t waste any time on a great responsive experience! Well, hold your horses. You may have self selected your answers here.

A great developer experience includes a great documentation experience, and that includes mobile. I have seen transitions from desktop-only to responsive, as well as responsive from day one, and both have shown how important it was to go mobile, too.

Take one of the Google developer sites for example, and a recent slice:

mobile: 90+% of share
This slice is from a campaign, so bias, but directionally similar

Why is mobile such a big deal?

All documentation isn’t equal. There are a variety of reasons why someone ends up in your docs. The Web is a viral platform due to the sharing of URLs through all sorts of mediums (via Email, Twitter, Slack, etc). People are increasingly accessing these mediums via mobile, and are tapping in to read from there. I often read a lot of developer-oriented content on mobile, and will save it away and often revisit on desktop.

I also do a lot of memorization through mobile, using space repetition systems. A common task during the day will be saving some developer knowledge into my system.

This is somewhat akin to customers who browse for products on mobile and finish the transaction on desktop.

Beyond documentation

It has been fantastic to see the trend of developer documentation being seen as putting the manual online with some hyperlinks, and instead using the medium to add a lot of interactivity to help you learn.

The best way to learn is to do, and it is important to be able to feel how things work and play with them. We have embedded Glitch into web.dev as an example of bringing you tight playgrounds to explore, and remix for your own experimentation.

How do you want this type of content to be approachable on mobile vs. desktop?

The other important realization for me has been integration. Developers often end up in your docs via search, and they rarely probably go to your root domain and just read read read.

Take time to look in the Search Console to see your analytics to see how users are getting to you, and make sure that you have the content they need. You need a base of reference documentation, and then can walk up the chain to use cases, and finally verticals.

Look for other areas of integration.

  • Where do your developers live?
  • Their IDE? And certain plugins?
  • Do you want to reach them on StackOverflow or Glitch?
  • Do your error messages link out to documentation to help?
  • Do your docs work offline? (e.g. if someone is reading on the subway to work, or generally stuck in poor and variable connectivity)
  • Do you include code from source files that you have tests running against to make sure that a copy paste works?
  • Have you built a connection between the tools and your documentation so it can be surfaced inline?

There is so much to do, and while “docs” are a first class citizen, it is also important to recognize that good tech writers are still under-rated!

The right thing to do, is the right thing to do.