[HN Gopher] A Product Engineer's Guide to Platform Engineers (2019)
___________________________________________________________________
A Product Engineer's Guide to Platform Engineers (2019)
Author : absolute100
Score : 54 points
Date : 2021-04-25 18:59 UTC (4 hours ago)
(HTM) web link (rinaarts.medium.com)
(TXT) w3m dump (rinaarts.medium.com)
| kazen44 wrote:
| is this "friction" to just the same as the traditional orthogonal
| relationship between developers and operational teams?
|
| One want to introduce new features into the system, the other has
| the job of maintaining stability so the service is actually
| available to it's users.
|
| in my opinion a good metric on how "fast to move" is hard to
| define. The "Move fast and break things" that is popular in
| sillicon valley does not work when your services are used by
| critical systems. (Think, water supply. power supply, medical
| etc). But moving too slowly has the disadvantages of being (too
| late) to market. It's a very fine balance to strike, if not
| impossible to reach.
| chaosphere2112 wrote:
| This is very on point. We have platform and product in entirely
| different reporting structures that meet just below Sundar; this
| leads to hysterically different cultures. My team is trying to
| straddle the product/platform divide right now and it's a
| constant learning experience.
|
| A recent example: someone asked me for my team's planning
| schedule, specifically when we figure out what we will be doing
| for the next six months.
|
| My only response is "we don't do that here"; my team has to
| constantly juggle projects to load balance downtime on projects
| (most of our work is very sinusoidal in how much time it demands
| in a week), and we pick up new ones that are important enough to
| add to the load from time to time.
|
| The platform folks set out in December last year with a mission
| for all of 2021; the design is flexible, but they know exactly
| what the goals for their year are.
|
| When one team has projects that take an arbitrary amount of time
| to "get right", and the other has more reliably predicted cycles
| that just depend on coding output, things get a little hairy.
| Mostly just takes a lot of empathy for the folks on the other
| side, though.
| a-dub wrote:
| she leaves out a third category: ai/ml/ds, which also has huge
| cultural differences with traditional product and infra/platform
| teams. check out hilary mason's recent interview in the twiml
| podcast. she confirms something i've suspected for a very long
| time: agile is a bad fit for ml enhanced product/project
| development.
| PLenz wrote:
| The biggest issue I've had with bridging the DS<>Product gap is
| that our (DS) work is not linear and often not incremental.
| Sometime we go backwards and sometime we have to build for a
| really long time only to discover that this way doesn't work
| and we'll have to do something else and that there is usually
| no stopgap. ML-based solutions often don't work at all until
| they work.
| yarg wrote:
| The problem with product is that they care about individual
| features and not features in general.
|
| This leads to an inability to see the overlap across product
| distinct features that all seem largely the same from a platform
| perspective.
|
| The goal for platform is to take the overlap and push it down the
| stack, behind an API - hiding the subset of complexity that
| product does not need to be exposed to.
|
| Platform gets to hide the dragons, and product gets an API that
| allows for features to be implemented quickly and cleanly (it
| also provides improved constraints from a testing perspective).
|
| However, when there's a feature that cannot be implemented
| against the constraints and features currently imposed and
| available, things slow down - until platform figures out what new
| abstractions should be presented to allow for the new feature to
| be implemented.
|
| It does not matter overly if platforms initial implementation is
| well implemented or hacked into place - fix it later, but try to
| do a good job on the abstractions (this will allow for product to
| cleanly implement the new feature and for the platform side
| technical debt to be handled later on, without major impact to
| product).
|
| Which is the long way of saying "It will be ready when it's
| ready".
| tomnipotent wrote:
| I think the platform in your example is still product. If
| platform is aware of the specific features in product, then
| it's not high enough up the stack to be platform. A storage
| service doesn't know what it's being used for. A messaging
| queue doesn't care what the publishers or consumers are doing,
| or a log aggregator the context of messages.
|
| Platform solves cross-cutting concerns generalizable to
| multiple projects or difficult scaling problems of specific
| products, and there will be many things that product teams do
| that look like platform-territory but do not need to scale or
| be abstracted for use elsewhere.
| Syzygies wrote:
| > 25 x 10^6 is, roughly, what separates us from orangutans: 12
| million years to our common ancestor on the phylogenetic tree and
| then 12 million years back by another branch of the tree to the
| present day orangutans.
|
| > But are there topologists among orangutans?
|
| > Yes, there definitely are: many orangutans are good at
| "proving" the triviality of elaborate knots, e.g. they fast
| master the art of untying boats from their mooring when they
| fancy taking rides downstream in a river, much to the annoyance
| of people making these knots with a different purpose in mind.
|
| https://www.ihes.fr/~gromov/wp-content/uploads/2018/08/manif...
|
| Whenever anyone refers to another sentient being as stupid, the
| assessment tends to say more about the speaker.
| barnaclejive wrote:
| TBH, I stopped reading when I saw the first meme/gif.
| tayo42 wrote:
| As someone who works on an infra or platform team at work, this
| is a nice thing to read. Wish more people at work had some
| empathy for the teams that support them. I really hate having to
| do customer service tasks at work. Surprisingly there's a lot
| entitled engineers to deal with, despite the fact I only support
| a few hundred. In a company we are all co workers, we work
| together. I'm not here to respond to demands from any one. I'll
| stop before this turns into a rant hah
| juancn wrote:
| I work platform, a quick project is one or two quarters, a decent
| sized one is multi year, will likely take several deployments to
| roll out and at least a quarter for testing and stabilization,
| but when we deliver it to the several thousands clusters it will
| serve, the chance of a serious incident is close to zero.
|
| For this to work, we need to anticipate future requirements. We
| monitor usage patterns, make proyections, study the market our
| company serves and try to see trends and shifts. We care about
| what competitors are pushing and what complementary industries
| are doing. We are aware of the business, but not in the same way
| product does.
|
| When our plans work (and they mostly do), we usually deliver at
| the right time when the company needs it. We saw a shift in
| market patterns that would affect load a year ago, so we started
| working on scaling certain part of the system. It took us a year
| to get there, but when it was needed, we had it ready.
|
| Sometimes people ask for things that come out of the blue. We
| were unable to anticipate them and the work to get them done will
| take at least several quarters.
|
| These scenarios are the hardest, when you need to push back, but
| it's not that we're not doing anything, we're reshuffling several
| quarters of planning to adjust to the shift in reality, so the
| next time you ask for something, it's ready, because we started a
| year ago.
| absolute100 wrote:
| 12 minutes read.
|
| Rina Artstain the pains and focus areas when working as a product
| engineer with platform/infrastructure engineers. It's remarkable
| how little software development is actually about writing code as
| the company grows. Unless you treat your company as a product,
| trying to scale out and scale up the emotions involved, you're
| most likely to slow down as you get bigger. Any authentic
| incentive (to the people you have and those you want to attract)
| that increases empathy between teams has to be proactively
| promoted.
| ad404b8a372f2b9 wrote:
| I thought I had a stroke reading this. 95% sure that's it's a
| bot.
| dang wrote:
| Could you please stop posting like this? See
| https://news.ycombinator.com/item?id=26930434 from yesterday.
___________________________________________________________________
(page generated 2021-04-25 23:00 UTC)