Where does Ops planning fit into front-end architecture?

[micahgodbolt]

I brought up the topic of performance budget today and it got me thinking about where ops fits into front-end architecture? Here are the 3 options I see:

1. Ops is a separate discipline that is more concerned with the delivery of the website than it's creation (and just like server configuration, is outside of the FEA circle of influence)
2. Ops is a discipline that, like front-end developer, implements and maintains the ops framework set forth by the front-end architect.
3. Does it really matter? Some architects will do some ops work, and some won't.

[andrewdc]

I think that the Front End Architect role should bridge this discipline a bit, as performance crosses several roles and technologies in a stack. It seems like a good understanding of the delivery mechanisms, bottlenecks, best-practices, etc would fall on the FEA to promote and encourage across development teams. Similar to how a good FE designer will bridge the user and product gap and represent their needs. At the very least, a solid FEA should be a resource for guiding performance goals and strategies across a good dev shop.

[micahgodbolt]

Yup! I'm 100% with you. If nothing else, I'll be putting performance testing into the 'testing' pillar, and make meeting that budget be part of the process of development.

Sometimes it comes down to development approach. There is less sense in perf testing your styleguide, unless you are building entire pages. And if you are using a CMS, you need to be prepared to factor in the weight of cms code as well (hello drupal!).

But this could be about setting a perf budget for individual components? Or at least set a budget of CSS and JS file size, as well as font/images etc.

I'd have to be the ops dev who had to work with an architect who could care less about performance, and it was the ops job to clean things up :)

[andrewdc]

Yes, and every team needs a person to direct how the front end assets specifically are built and delivered. In my experience, a strict Ops person isn't well acquainted with ways to optimize top level code, css output, gzipping, etc.

Just thinking out-loud, but when a question on this arises, who do you usually ask? Usually it's a front-end person, and not your (overworked) devOps fellow who is usually juggling deployment and release issues.

A person who can tie together this stuff to the rest of the stack and deploy strategy would be a huge value on any team.

[febbraro]

I dont see how you can have something you call "architecture" that does not represent the entire holistic application. FEA design decision can have considerable impact on how the layers in your stack collaborate which will drive how these things are configured, deployed and scaled. I dont think you can say "architecture" then say "that part is not my concern" So I think to be an architect, or to do architecture, you need to be involved in broad aspects.

[micahgodbolt]

Yeah, I'm certainly convinced that the FEA should have a large hand in setting up the tools and processes needed for a performant site. The question then is how is the handoff handled between architect and front-end ops. Just like a architect hands off blueprints to the contractor, what decisions does the FEA make vs leaving to a dedicated front-end ops person.

For instance, FEA says "we need a CDN". And the front-end ops says "ok here are my suggestions, and how each would fit into our current stack"

[febbraro]

I like to think of things much more as a collaboration than a "handoff" No one should be going away. As systems progress changes and refactorings need to be made, those should be made together. Removing handoffs in favor of collaboration and open lines of communication are the key to successful systems that require cross-disciplinary teams and skills.

[febbraro]

So in your example, FEA might not say they need a CDN, a CDN is rarely a real value based customer requirement. The requirement is more around performance, TTFB, scalability, etc. The conversation happens with team and client about how to best tackle those (although in many cases you know already) and CDN is the result of a conversation about meeting value based requirements. A CDN in an of itself should not be a req.

[micahgodbolt]

@febbraro great points! I'm enjoying having someone bring up some different views in this discussion.

After a bit of thought, I realized that the reason I hadn't originally put much ops into my Front-end Architecture pillars. At Redhat.com, where i've been formulating these thoughts for the past year, the ops portion of the front-end was already in great shape, and in the hands of a incredibly competent back-end developer.

Obviously, this is no excuse to not have thought about how our bits are getting to the client, but they were the rose colored glasses I'd been looking through over the past year.

I'm starting to think that I'm still OK with 4 pillars, and that Code might become Assets, testing can include performance budgets and other tests like TTFB, and lastly Process includes full lifespan of a piece of code, from the developers editor, to the clients browser.

There will be times where the front-end architect is paired with a back-end architect (or software architect) and some of those delivery roles are taken off their plate, but there will also be times where there are little to no back-end architecture other than the platform (Acquia, Pantheon), and the FEA will have to wear all the hats.