"Monoliths for Micro-frontends" -- why old architectures lobby for modern web apps
Micro-frontends are the rage. I suppose the microservices movement just had to breach the firewall and conquer the frontend frontier. That's all good by me: if small is in, count me in!
However, is this the only appropriate use of micro-frontends? If you don't have microservices yet, how might you get started with micro-frontends.Or do you need to be even taller to use micro-frontends than you had to be to use microservices?
Before you inject growth hormones into your architecture (or your physique), give me 45 minutes of your time. I may be able to convince you that micro-frontends make just as much sense with legacy, monolothic backends as they do with sleek, svelte microservices.
Outline/Structure of the Experience Report
2. Applications in a microcosm
a. Independent domain
b. Independent data storage
c. Independent development
d. Independent deployment, scaling, monitoring, maintenance, retirement ... you get the drift
a. What are they
b. How are they different from traditional frontends
4. The monolith dilemma
a. Vast domain
b. Coupled data storage
c. Intertwined development
d. Intensely choreographed deployment, no horizontal scaling, superficial monitoring, no retirement (not counting "dishonorable discharge")
5. Grafting micro-frontends on top of legacy monoliths
a. Sequestered development
b. Decreased volatility of legacy code
c. Potential path towards an "honorable discharge" for the monolity
6. Unanswered questions
a. Could this spawn a hydra-architecture?
b. How about team cadence?
c. And system-integration testing?
Conclusion and Q/A
At the end of this session, attendees ought to be able to:
1. Understand the benefits and applicability of micro-frontends
2. Articulate how micro-frontends may prolong the life of a legacy monolith
3. Ask the deep questions that are necessary to validate such an architectural approach.
Software developers, software architects
Prerequisites for Attendees
An awareness of microservices architecture
An awareness of front-end technologies
Familiarity with the challenges of sustaining and supporting legacy backend systems
schedule Submitted 10 months ago
People who liked this proposal, also liked:
Saleem Siddiqui - So what happens after you fail fast?Saleem SiddiquiPrincipal ConsultantSPR
schedule 11 months agoSold Out!
"Fail fast" is only half the bumper (or laptop) sticker; and the other half isn't "fail often".
"Fail fast" isn't an invitation to engage in Pyrrhic victories or outright losses. In this talk I'll share how failure can be used as a ratcheting mechanism to increase the probability of long term success. I will draw upon not only my experience, but also the audience's, to elicit the kinds of failures that are worth seeking and those that are worth avoiding.
Saleem Siddiqui - The Tyranny of Taxonomy -- how our need to categorize things makes every problem harderSaleem SiddiquiPrincipal ConsultantSPR
schedule 10 months agoSold Out!
Perhaps it's evolution, perhaps it's the post-agricultural-revolution culture. Whatever the reason, we like to categorize things. Young children play "Name, Place, Animal, Thing", and older ones Dungeons and Dragons -- learning from an early age how to classify objects. Still older "kids" compartmentalize roles, tasks, opportunities, and risks at work.
This need to categorize things can hinder our ability to solve problems. We create categories too early, allow them to seduce our mental models too deeply, defend and fight for them with much zealotry, and cling on to them for too long. When designing and building software, things change swiftly and often -- a rigid categorization scheme can be a stumbling block.
In this talk, I'll present some common (and surprising) categorization schemes that are best used sparingly in software design. With example, candor, and humor, I'll show you how we'd all be better software artisans (and perhaps, people), if we used categories less frequently.