flurdy’s ranting

Mob Together: When AI Joins the Team

2026-02-04T12:52:00+00:00

What is mob programming?

Mob programming is simple: the whole team works on the same thing, at the same time, in the same space, on the same computer.

One person types (the “driver”), while everyone else navigates - discussing, suggesting, reviewing in real-time. The driver role rotates regularly.

It sounds inefficient. Five people doing one person’s work? But something counterintuitive happens: you go faster, not slower.

Decisions happen immediately instead of waiting for reviews
Knowledge spreads across the team naturally
Bugs get caught as they’re written
No merge conflicts, no integration problems

Not meetings, not chaos

Mob programming is not a meeting. You’re producing code the whole time. It’s also not chaos - there’s structure, rotation, and focus.

Think of it as continuous code review with immediate implementation.

Life happens, code flows

One underrated benefit: flexibility. People take breaks, step out for meetings, leave early, go on holiday - and the code keeps flowing. No one is a bottleneck because everyone shares the context.

Compare this to solo work where one person’s absence means their work stops, their PRs wait for review, and their knowledge stays locked in their head.

Fewer rabbit holes

Like pair programming, mob programming naturally prevents waste. When you’re about to spend two hours on a “nice to have” abstraction, someone asks: “Do we actually need this?”

Rabbit holes get spotted early. Unnecessary code never gets written. The group maintains focus on what matters.

Image by Freepik

The solo AI trap

AI coding assistants are transforming how we work. But here’s what often happens:

Each developer on your team works alone with their AI. They each:

Interpret requirements differently
Make different architectural choices
Build overlapping or conflicting solutions
Create code the others don’t understand

You end up with multiple teams inside one team. Five developers, five directions, five interpretations. The AI amplifies individual productivity - and individual divergence.

Solo developers with AI agents are highly productive. But productive at what?

Code gets written fast. Integration takes forever. Debugging someone else’s AI-generated code is painful. The team fragments.

The mob + AI sweet spot

Here’s the insight: AI agents don’t replace mob programming - they supercharge it.

A small mob (4-5 people) working together with AI agents:

Shared context - Everyone sees the same prompts, specs, and AI responses
Collective prompt refinement - Four minds crafting better prompts than one
Parallel execution - Run multiple agents on different tasks, all aligned
Real-time review - AI output gets immediate human scrutiny from multiple perspectives

The mob provides what AI lacks: judgment, context, and coherence.

AI generated image with Nano Banana. CC-by

Why smaller mobs work better with AI

Traditional mob programming sometimes used larger teams (8-9 people). With AI, smaller works better:

More active participation

With 4-5 people, everyone stays engaged. No one becomes a passive observer. Each person can meaningfully contribute to prompt crafting and output review.

Parallel agent orchestration

A small mob can effectively coordinate multiple AI agents working simultaneously:

One agent implementing a feature
Another writing tests
A third updating documentation
An agent can be tasked with planning etc

More people doesn’t help here - you need coordination, not headcount.

Faster rotation

Smaller groups rotate the driver role more frequently. Everyone stays sharp and engaged.

The ideal team

I believe small mob teams with shared AI collaboration represent the most productive team structure we’ve found yet.

Not individuals racing ahead with their own AI agents. Not large teams with coordination overhead. But 4-5 people, thinking together, prompting together, building together.

Mixed backgrounds, shared goal

The ideal mob isn’t five backend developers. It’s a mix - someone with frontend experience, someone who knows infrastructure, someone strong on architecture, maybe someone closer to product.

This diversity is a feature, not a problem. When you hit a CSS issue, the frontend person leads. When deployment questions arise, the infra person steps in. Everyone learns from each other constantly. Knowledge spreads without scheduled “knowledge transfer” sessions.

You don’t need experts in everything. You need enough overlap to communicate and enough diversity to cover the problem space.

Flexible focus

Not everyone needs to stare at the same screen every moment. While the core group drives the main story forward, someone can branch off to investigate:

Research an API the team will need
Spike a potential approach
Check documentation or find examples

They stay connected - same call, same shared context - and rejoin the main flow when ready. The investigation feeds back into the mob’s work rather than becoming a separate track.

This flexibility means the mob moves fast on the main path while still handling the side quests that would otherwise block progress.

The sum is greater

The AI handles the typing speed. The mob handles the thinking speed.

Four people with different perspectives, reviewing AI output together, catching issues the AI missed, asking “but what about…” - this produces better results than any individual could achieve, no matter how good their AI tools.

How it works in practice

Shared specifications

The mob starts by agreeing on specs and acceptance criteria together. This alignment - which solo developers skip - means AI agents receive consistent, well-thought-out prompts.

Collaborative prompting

One person drives, but everyone contributes to the prompt. “What if we ask it to…” becomes a team activity. The resulting prompts are clearer and more complete.

Parallel execution with oversight

The team can run multiple agents on related tasks. Because everyone has shared context, anyone can review any agent’s output. No knowledge silos.

Immediate course correction

When an AI goes in the wrong direction, the mob catches it immediately. No wasted hours following a bad path alone.

The fragmentation problem

When developers work solo with AI, you get:

Architectural drift - Each person’s AI makes different structural choices
Style inconsistency - Code looks like it was written by different teams (because it was)
Knowledge silos - Only one person understands each piece
Integration nightmares - Merging divergent AI-assisted work is painful

A mob stays aligned by definition. There’s one codebase direction, one architectural vision, one understanding.

Photo by StockCake

Remote mob programming

You don’t need a physical room. Remote mob programming works surprisingly well:

Screen sharing (driver shares their screen)
Video call for discussion
Shared documentation for specs and context
Rotation timer to keep things moving

In some ways, remote is better - everyone has the same view, recordings are easy, and introverts often participate more freely.

Beyond one driver

Tools like VS Code Live Share change the dynamic. Multiple people can edit the same file simultaneously - one person leads, but others can jump in to fix a typo, add a comment, or demonstrate an idea.

The strict “one driver” rule relaxes into “one person in charge, flexible for input.” This can accelerate things further - a navigator spots a missing semicolon and just fixes it instead of dictating the correction.

Traditional mob purists might object, but the goal is flow, not rules.

Getting started

If you haven’t tried mob programming:

Start small - One afternoon, one feature, 3-4 people
Set a rotation timer - 10-15 minutes per driver
Pick something meaty - A real feature, not a trivial task
Include the AI - Have your coding assistant open and visible to all

The first session will feel awkward. That’s normal. By the third session, you’ll find your rhythm.

What you’ll notice

Fewer “how does this work?” questions later
Less time in code review (it already happened)
More consistent code style
Better prompt engineering as a team skill

Try it

If your team uses AI assistants, try mobbing for a week. You might find that working together - truly together - is faster than working apart.

One team, many agents, shared understanding

Resources

Books

Software Teaming: A Mob Programming, Whole-Team Approach - Woody Zuill and Kevin Meadows. The definitive guide, now in its second edition with material on remote mob programming.
Code with the Wisdom of the Crowd - Mark Pearl. Practical guide to getting started with mob programming.

Podcasts

The Mob Mentality Show - Chris Lucian and Austin Chadwick discuss mob programming with guests. Over 300 episodes covering everything from getting started to advanced patterns.
Mob Programming with Woody Zuill - Mountain Goat Software podcast episode with the originator.

Websites

Mob Programming - Woody Zuill’s original site with resources and sample book chapters
Woody Zuill - Workshops, talks, and coaching on software teaming

YAGNI × 100 with AI

2026-02-02T16:00:00+00:00

You Aren’t Gonna Need It

YAGNI - don’t build features until you actually need them. History taught us that if we added all the features we thought we would need, projects would be late, over budget, or never finished at all. Most of those extras were rarely needed in the end.

Release early with basic features and see if more polish is actually needed. That way you ship on time and budget, but also gain real feedback on what works. You may add a few more features later - but only a tiny subset of what you thought you needed.

The old friction was our friend

Before AI, there was natural friction. Want to add a caching layer? That’s a few hours. An abstraction for three database backends? A day or two. A plugin system for your internal tool? Block out a week.

This friction served as a filter. When building something unnecessary costs significant time, you think twice. You weigh the trade-offs. You ask yourself: “Do I really need this?”

YAGNI saved days, weeks, months. It saved projects, businesses and careers.

The New World, the AI World, No Friction

With AI agents, that calculation changes dramatically as AI removes the friction. Now you can:

Generate a complete caching layer in minutes
Build abstraction layers with a few prompts
Create plugin architectures before lunch

The friction is gone. And with it, our natural defense against over-engineering.

AI makes it so easy to write code that we forget to ask if we should

The hidden costs remain

But in fact the real costs was not just the development time, more code means:

Maintenance burden

Code that exists must be maintained, updated, and understood
Bug surface area

More code means more places for bugs to hide

But also on individual level:

Cognitive load

Every abstraction adds complexity for the next developer (including future you)
Onboarding friction

New team members must understand code that serves no purpose

Not just code

Even with super charged AI development, if you keep adding features fast, each one will still delay a project more and more:

Testing overhead

That unnecessary feature still needs tests.

And often manual QA, or at least some manual UX test to ensure it has been done.
Documentation

More features, means more documentation and training

Image by Hooba Design

Yagni × 100 to avoid AI bloat

With AI agents ability to create features at such rapid rate, you will need a strict discipline to keep the project on course and apply YAGNI all the time to stop the bloat.

AI increases output, not understanding. If you build five extra features you do not need, you also create five extra surfaces for bugs, support, and distraction.

The discipline shift

In the old world, we needed discipline to push through and finish features.

In the AI world, we need discipline to stop ourselves from building features.

The AI suggests adding configuration options, extensibility points, error handling for scenarios that won’t happen, abstractions for problems you don’t really have. And because it’s so easy, the instinct is to say yes.

Before you build

Before asking your AI assistant to build something, ask yourself:

Is this solving a real problem I have today? Not a hypothetical future problem. Today.
What’s the simplest solution? AI loves to suggest comprehensive solutions. Push back.
Can I delete this later? If the code is deeply integrated, think harder about whether you need it.
Would I write this by hand? If the effort would have stopped you before, maybe that was wisdom.

Resist

The best code is still no code. The second best is the minimum code that solves the actual problem.

AI makes it tempting to skip straight to comprehensive solutions. Resist.

AI in SDLC = the End of Outsourcing?

2025-08-11T22:00:00+00:00

Is outsourcing development business at risk? By AI agents? Does it replace the reasons people outsource?

Why outsource?

Companies outsource projects, teams or whole departments for several reasons.

What are the benefits?

Capacity

Ability to run more projects in parallel than they have to employ and train staff for.

Ability

Some projects may require skills the company does not have or want to have.

Flexibility

The ability start and cancel projects without retaining permanent employees. Or change requirements and skills required on a whim.

No-one sheds tears for a consultant if a project gets canned.

Photo by Stockcake. Public Domain

Cost

Local consultants costs more per hour but you do not pay for them all the time. Nor any of the benefits etc. If the project is not started, is paused or when it is finished that costs is 0.

Risk

Reducing the risk of enlarged employee salary budget.
Risk of shortage of staff means running out of time to launch project.
Risk of the company falling behind by not keeping up with features.

Why outsource to cheaper countries?

And more importantly many outsourced projects is outsourced to much cheaper countries, where maybe a whole team cost less than one permanent employee.

That means either

the scale and capacity of the companies projects can be much larger
Or that the budget can be much smaller.

In theory.

Photo by Stockcake. Public Domain

Fallacies of outsourcing

There are many downsides to outsourcing: (Though that is really out of scope for this article.)

Company culture and harmony:

Often the companies employees feel marginalised by the focus the new teams and the influx of the new co-workers. Or the outsourcing company and consultants have completely different norms and behaviour of the original staff.

Productivity

Bottle-necks and communication overheads may mean the company actually ship less. Timezone differences, culture misunderstandings, etc makes communication harder and thus productivity lower.

Hidden costs

Especially with more remote teams there will be the need to hire more intermediate people to communicate and portray to the team and the hiring company with the requirements, questions and statuses.

Knowledge Churn

With consultancies the time to train and retrain is considerable as there normally is a big turnover of staff on the project and outsourced company.

Photo by Stockcake. Public Domain

Comparable use of AI

Now what if an in house development team uses AI agents in their SDLC - how does that compare?

Like junior devs

Like I discussed in Pairing AI Agents, AI in SDLC is like working with junior developers.

Developers become architects and managers

And since it is like delegating to a junior, every developer transforms into their own manager/architect with responsibility to create the requirements and delegate it to the AI agent(s).

Horizontal scaled up AI use

With every developer using AI in such manner is the outcome similar to outsourcing?

SDLC with AI benefits

Lets compare the pros and cons of outsourcing discussed briefly above.

AI Capacity

If the team goes all in with AI agents the theory and current data indicate they can now scale the horizontally bandwidth by quite a bit. A team can be less developers, so they can have more teams with the same amount of developers.

AI Flexibility

Whilst the number of engineers does not change, the skills of the AI agents can make the developers much more flexible in terms of programming languages and frameworks.

AI Cost

AI agents do cost a lot especially if you go all in. But so does outsourcing. It becomes a calculation of gains v cost.

AI Risk

The employee salaries does not increase.
The AI agent cost increases but on a whim can be dialled to 0.
Falling behind risk is low as the AI skills are up to date.
One risk is not keeping up the developer skills in line with the AI’s skills.

AI fallacies

And the negatives of using AI agents in SDLC versus outsourcing:

AI Productivity

The productivity gains could be huge. If managed well on the individual level.

YAGNI is vital as with great power comes great responsibility… to not bloat the requirements and features by including everything, and never really finish/deliver.

AI Hidden costs

The AI agent cost is visible. There are no more salary costs.

AI Knowledge churn

The skills of the AI is permanent, though undoubtely which AI agent is used will constantly be changing in a AI ability race.

The skill in using the AI is worth training and focussing on.

As well as making sure the skills of the developers don’t wither. They need to supervise and work in conjunction with the AI to avoid AI slop and rotting code.

Photo by Stockcake. Public Domain

Outsource or AI?

As you can see above many of the benefits of outsourcing is also prevalent with using AI in SDLC. And many of the negatives are irrelevant or reduced.

So should companies just use AI instead? It is not quite as black and white.

It depends…

As with all things each scenario/company will have different requirements that may make it more desirable or less desirable to use AI over outsourcing.

For many, yes use AI instead

For a lot of companies however they should just let the developers go all in with AI and not outsource. Or not outsource their core business skills instead just their fringe/maintenance projects.

For some, still outsource

Some companies they just do not want many developers or have the ability to train theirs, so for them they still need to outsource most of their IT projects.

Best of both worlds: The consultancies use AI as well

Of course all the consultancies that offer outsourcing will also use AI agents.

Their own consultants will learn the skills to delegate to AI agents as well.

That means it should require less consultants to fulfil the requirements from the hiring company. So in theory their cost / price should be less…

What about outsourcing to cheaper countries?

An area that I think will be hit is outsourcing to remote cheaper countries.

The need for them will decrease as more companies will be able to either do more internally or hire local consultancies but fewer headcounts so the need to save money will be less of a priority.

Time will tell.

Disclosure

I, the author, Ivar Abrahamsen, have worked as a consultant for a huge multinational consultancy that offered outsourcing, I have been hired in on many projects to a smaller consultancy that do both local mixed with remote outsourcing. As well as a permanent employee of companies that outsourced parts of their projects. Some of the outsourcing have been to India, some near-shore like Czechia, some in the similar timezones in South-Africa and Argentina.

I am an independent consultant and available to help your company’s AI journey: eray.uk

Pairing AI agents? They’re just like juniors

2025-08-02T13:27:00+00:00

Can we pair program with 2 agents together, is that similar to pairing juniors?

As I and all of us are getting used to use AI agents in our development flow, I am wondering if we should learn from our experience of the value of pair programming, and with that I mean let AI agents pair with each other?

That should get some of the benefits of code quality though less of the knowledge sharing that pairing brings.

(Summer of 2025 caveat. Who knows where we are in a year, 5 years or 20…)

Junior developers

When using AI agents in your SDLC, with your normal development task, you quickly see the patterns of working with junior developers in a similar fashion.

They can be smart and develop great things by themselves.
With a simple task description they may create great solutions.
They think of things you did not see and present solutions solving that.
They do sometimes see what others have done and keep applying the standard.

]

Image by Stephane from Pixabay. Pixabay License

Junior dev risks

But:

They can also go on a crazy train and unnecessary rewrite fundamental parts of the architecture.
They make rookie mistakes that more senior developers all did and learnt not to do.
They can overcomplicate; and try and do too much instead of focusing.
Or they ignore red flags and hyper focus on the tiny tasks ignoring the blatant side effects.
They may write extremely bloated code and solution when a DRY terse solution would be much better.
They may not be aware of prior art and reinvents the wheel.
They do not consider the bigger picture, of how the solution works with other systems and existing solutions.
They do not consider the risk and cost on supporting a solution, extending it, training new devs, fixing bugs 5 years in the future etc.

Now seniors (me included) also do these mistakes, but hopefully a lot less after having learnt from early days mistakes.g

Junior = AI agent. For now.

Now it is obvious that AI agents seem to behave like a junior dev, though with time the LLM models may train and train and become more “senior”.

But in essence I treat the AI agents as a junior dev that I have to oversee.

]

Photo by Kampus Production. Creative Commons license

Guiding Juniors

You do need junior developers, a constant income of new “blood” is essential. For new ideas, avoiding stagnation and counter natural employee turnovers. And most companies and leaders know how to reduce the risks and side effects of having junior developers.

You have a thorough recruitment process to hire smart, independent, eager-to-learn and responsible employees.
You offer training to always expand (and maintain) the developers’ skills and knowledge.
You follow up and regularly talk how their process is going and if any changes is needed.

Onboarding and Guidance

But the most effecting is having a tried and tested modern onboarding process.

This would usually involves pairing up with another developer for a while at the start to ensure the path chosen from the go is the correct one.

You teach them the technology, architecture and projects but also the culture and the norms of the company and team.

With some guidance the mistakes and the risk of car crashes can be minimised. It is okay to break convention, try something new, just in a sensible manner.

Pair programming

Now I have preached many times on the subject:

In my mind it is essential you keep pairing beyond the initial onboarding.

And not just junior with a senior but junior+junior and senior+senior.

]

Image by Creative Matters

Guide an AI agent

It is the same with AI agents.

You guide them with advise
You tell them what to do with clear prompts
You give them rules to abide by
You give them specs to start work on

Pair with an AI agent

Essentially sometimes it is very much like a top down Senior/Tech-Lead instructing what a junior should do.

This depends on what tasks you and the AI are doing. A more hands-off task is a bit more like normal senior/manager to junior delegation of tasks.

However when it is an intensive task I think of it as a pair-programming session. Except I am always the navigator/co-pilot and the AI is always the driver/pilot. It is always the navigator that is actually in charge.

AI Agent behaving like a junior

That is mostly to avoid a lot of the same negative/risks listed at the start for a junior dev.

The AI Agent often goes on a completely wrong tangent, or forgets something basic about the SDLC of this project. A hands-on navigator keeps it inline.

An experienced navigator also good at catching and knows when it needs to prevent the AI going down a futile deep rabbit hole for a simple solution.

This means the navigator has to be on alert and continually aware of each step the AI is changing.

Pair 2 AI agents with each other.

Now a solution I was thinking to avoid the pitfalls of a junior dev / AI agent maybe the AI should pair up with another AI? To keep it in line?

Perhaps a Google Gemini Pro agent can be the navigator for Claude Code Opus agent?

]

Designed by Freepik

Why pair 2 agents?

To try to avoid the obvious negatives of AI agents (and junior developers),

avoiding going down rabbit holes
complete rewrites
checking if rules was adhered to
keeping to conventions

And general common sense that I hope you can prompt an AI to achieve.

Unnecessary

People will correctly say that within the LLM there are probably layers and branches of the LLM doing exactly this already. So is the 2 agent pairing redundant?

I think if they are 2 different LLMs then they can police each other better.

It is worth an experiment. I will try to see how to do it.

AI in charge

Now, the thing is, when will the AI be the senior delegating tasks to human junior developers?

MVP is too late, launch first!

2023-06-14T19:00:00+00:00

Launch first

The first thing a project should do is to go live. Yes, live - as in prod. Immediately.

“We have not made anything yet!”

That is true, but that should not stop you. You can go live with hardly anything. There are many ways to define a go live / launch.

Dark launch

Most of the time it will be a dark launch at the start.

Also go live now does not neccesarily go live with the whole intended system. Just a tiny partial launch.

Maybe all you go live with is a small listener that mirrors all requests to the current legacy system and then also puts it on a queue nothing listens to yet. The old flow still handles everything. But soon MVP and more will start to act on the replicated requests as well.

Maybe it is a tiny app that gets called with real live request but simply redirect to the old system like a Facade design pattern.

Or an unlinked website url, being mostly blank at the start. This does run the risk of being exposed if URL is leaked or sniffed somehow by search engine crawlers.

Or your ingress tools can then start to filter 0.001% of traffic to your service etc.

Maybe other minor launches that act similarly.

]

Photo via Safaris Africana

MVP is too late

Waiting to launch until when a MVP is ready may be some time. Even a small MVP is a significant delay.

Delaying till MVP it basically a mini big bang release.

And you loose the benefits of launching even earlier:

]

Photo by spaero from Pixabay. Pixabay License

Real data

The important part of launching early is to start using real production data and run in the real production environment.

Instead of faking maybe unrealistic traffic, or even totally ignorable data, in a substandard environment.

Real metrics and feedback

The feedback from metrics and other feedback are from prod usage and more valuable than internal testing feedback.

And with early usage data the development can adjust sooner.

Iterate on a live product

Better to launch early and iterate on it until you can launch the MVP and beyond. The feedback from real usage is vastly superior to estimated responses.

]

Photo by pcdazero from Pixabay. Pixabay License

Focus on only deliver value

With a live product, only features that actually matter will take priority, and nice-to-haves that-noone-will-ever-use quickly gets culled.

Having a live product you will psychologically focus on fixing and implementing the missing exposed parts quickly.

Keep going live

With a minor part live you keep launching more parts live all the time. Eventually the whole delivery is live.

And then you keep going.

My real experiences

I worked on a few projects where we decided to go live very early.

]

Public domain

New retail rewards

I worked with a retailer that trialed out a new reward card scheme in a big project.

We launched after just 3 weeks. But only in one shop (out of over 1000 stores). And compensating the customers for their inconvenience of using a new incomplete scheme.

It worked marvelous. And was gradually expanded to more then eventually all the stores. The early and constant feedback was priceless. We also got early mirror event traffic of the real data flow which was essential in the success.

New insurance engine

With a client we launched a new risk pricing calculation engine very quickly. And part of the reason for that success was that we tapped into the existing legacy request events in prod from the start.

As we filled in our new services acting on these events the data lake of results quickly matched the legacy system and went beyond.

The success was significantly due to the live data feed we got in the first few weeks. That we could compare the old and new continually and deliver value immediately.

Blog now

On a personal level I posted about Blog quick. Blog now!, where I emphasised the idea of posting blog posts straight away when incomplete.

You then quickly want to fill in the rest of your blog post, with even more benefits detailed in that blog post.

Testing in prod

Part of why I think launching early is great is that I really value the testing in prod approach. With trunk-based-development, feature toggles, no PR gating etc, I think the value of having your project/system in prod quickly is an additional great benefit.

tl;dr

Launch early so you get real data and feedback. Before any features are written. Do not wait for any MVP.

No what ifs

2023-03-29T12:11:00+00:00

Ban What-Ifs in meetings

TL;DR

Many meetings drags on discussing potential what-if scenarios, don’t waste time on those.

Instead when you have agreed on the next step, finish the meeting straight away and focus on that step. Then meet again if necessary afterwards.

Less what-if - more focus.

What is a “What If”?

Discussions, planning, estimating a scenario that may happen. Usually followed by further “What-ifs” depending on its output. With responses planned in detail. It is a huge waste of time as most will never happen.

Not business-wide what-ifs

The necessity or futility of corporation-wide business scenario meetings are not the focus of this blog post.

This post is more about the smaller frequent team/project/department meetings what-ifs.

]

Photo by Jenny Hendershot via Backyard Assist

Drags on

Meetings that drag on forever is my main moan

Many meetings are a quick team huddle to discuss a particular task/issue. Often a plan to handle this issue is quickly brainstormed and agreed on.

But… then most meetings do not end there.

As mentioned at the top people start to discuss and plan what if the first solution does not work. And more iterations and decision trees beyond that for the second, third, etc solution. These becomes so speculative and of little value as usually situations change too much for them to carry much value.

]

Photo by LA Dreaming

Using allocated meeting time

These meetings that drag on I despise. It seems people try to just to fill the time allocated time instead of letting people leave to crack on. I used to love arguing these possible technicalities for the sake of it, but these days I just see the wasted effort.

10 minute meeting

If a meeting can finish after 10 minutes then great.

Those are good meetings.

Selfish

Quite frequently these never ending meetings can be due to the meeting organiser having a busy schedule, but often the rest of the attendees do not. Don’t waste their time due to your inability to decline meetings.

Depressing

Not just the wasted time is upsetting, but spending time and effort planning for a future that do not happen can affect moral. People may start to look forward to something they have discussed in detail only to realise later on that it will never happen. Over and over again.

License unknown

Meetings are expensive

Meetings themselves are expensive. The more the larger the crowd. People have basically downed tools during the meeting. And interrupts teams, pairs, individuals productivity a lot. So affects for longer than just the meeting allocation.

Analyses preparation before, estimation, documentation afterwards, etc are further expense on top of these meeting costs.

Anecdote

I still remember 15 years ago when I was working for a consultancy where most of the department was body-shopped to clients on-site as individual contractors. Sometimes however everyone was called into the HQ office for some basic info and “team” bonding. In one of these meetings everyone was in a large meeting room.

The CEO, or maybe it was the CFO, popped his head through the door. His eyes grew wide, nearly watering, as he saw 30 of his contractors that was not at the clients invoicing. He gasped: “Wow this is an expensive meeting!”

Plans Are Worthless, But Planning Is Everything

Misquote from Dwight D. Eisenhower

Photo by Designing Buildings

Is planning not essential?

Being unprepared is naïve and irresponsible.

But you do not need to predict the whole future, and plan and estimate it in detail all the time.

Your architects, analyst, UX researchers, project and product owners, etc will naturally have to have some foresight into the funnel coming up. That is in their job description, but no need to involve everyone in all of these when they are speculative.

Heads up

Sure, a quickfire of what can happen and what may be the future actions needed is sensible. And two-way communications is invaluable.

But drop the details and estimations until it becomes relevant.

Groom a little

I do not have a problem with Grooming your backlog with the team.

But not in every meeting. And only a tiny bit in brief sessions.

And I have a problem with the need for estimating, see below.

Optional inclusion

Feel free to include people, inform people of future plans but do no make it mandatory to plan what-ifs for everyone, all the time.

Optional departure

Or alternatively let people leave when you enter the futile What-If zone in a meeting?

Photo by Chris Reading from Pixabay. Pixabay License

Focus, iteratively

The next step, only

When you have agreed on what to do next, just end the meeting and focus on it together straight away.

And then only afterwards look into detail of the following what-ifs once you know the outcome of the initial step.

Then plan and focus for the new next step. Only.

Meetings are “cheap”

Not the time as explained above if in large long meetings, but organising quick short meetings with just the people concerned should be easy, and if brief relatively cheap.

These days a quick ad-hoc Zoom/Teams meeting or Slack/Discourse huddle is so effortless.

JITP - Just-in-time-plans

Only have planning meetings for eventualities that will definitely happen. And you know that only when it is just about to happen.

I an not a civil engineer, that may need to plan ahead in detail as physical construction issues can be expensive to undo.

But I am a software engineer. We can have meetings and plan just enough, act on it, evaluate, then plan just enough again. Iteratively. i.e. “Agile/Lean”.

No estimations

These problem stems often from the requirements to estimate everything. Instead we can benefit from the no-estimates convention. You would then have no need to continually plan future work in detail to have guestimates.

A lot of time and frustration would be spared.

My last few years have been on projects with no-estimation. It has been a lot more productive. And less frustrating.

Photo from Pxfuel. Public Domain

Impatient. Less theatre

Maybe a lot of these issues is due to that I seem to get more impatient as I get older, not less. With having kids and a lot more experience you would have thought I would be more mellow and understanding.

But I am not.

I really can not stand all the unnecessary theatre that happens all the time. I have no desire to waste any energy on that.

Go JITP! Boo What-if!

Degoogling

2020-08-12T21:12:00+00:00

Degoogling myself

I am in the process of detaching myself from Google. By using less and less of their services, so that I depend less on Google the company.

It is not easy. Google/Alphabet have services and applications that cover nearly everything that I use. And are often the best alternative, sometimes by quiet a large margin.

This degoogling process started years ago and is still in progress.

And then I also am “Regoogling” myself using new Google services. 🤦

(The title is a spin on Tor Norbye’s 2010 tweet when he cryptically hinted he was joining Google.)

Why degoogling

Risk.

Depending on just one company for a lot of my digital life is risky. Suddenly I may not be able to use any of their services or access my data. That could be very problematic.

Photo by Guma89. CC by-sa

Google might close down

Google/Alphabet may go bankrupt. Unlikely as they are a very profitable global company, but quick surprise financial disasters have struck big companies before.

Google might get banned

The UK or the EU may for some reason ban access to some of Google services. For lack of tax payments, monopoly infringements or political security reasons.

Or the US might ban access to European users for some whimsical reason.

Something like this might happen but usually with a lot of warning ahead of time and probably only affect a certain service temporarily.

Google might ban me

This is the most likely.

Many people misuse Google’s services and are rightly banned.

Unfortunately as Google services are used by so many millions they automate most of their interactions with their “customers”, including getting banned.

This has let to many false positives and innocent people getting banned. Some just temporary, some permanently from one of the services, and some a total and immediate ban from all services for life.

And the main problem is that it is Google’s policy to not to tell you specifically what they think you have infringed. This makes it hard to figure out how to you can fix whatever the problem is. Whether is it is an error, a misunderstanding, just a mistake, or nothing wrong at all.

If one service ban in error might lead to a total ban, including your email, all your documents, all your photos, analytics, servers etc it is very risky to rely totally on one provider like Google.

I got banned

I had an early taste of the automated false positives as I had an Adwords account closed for no apparent reason which lead me to wake up and realise they might come for me so I started the formal process of degoogling myself.

Degoogled so far

GMail

Whilst I do host my own mail servers flurdy.com/docs/postfix, for my main accounts they were still hosted with GMail.

I have migrated these to Fastmail. Highly recommended.

Search

Google search is still the best search engine.

But I have for a number of years used DuckDuckGo as my default search provider. But I still often refer to Google for some searches.

Android

I got so fed up with Android several years ago that I switched to IOS and can’t see myself changing that.

Blogger

I wanted to be more in control of my blog, and as part of reducing risk by degoogling myself I migrated my blog to a self-hosted Jekyll instance.

I wrote a blog post on why I left Blogger, and one on how to migrate/create a Jekyll based blog.

Google Drive

I have always used Dropbox and never used Drive as an online storage.

Chrome

5ish years ago I went back to use Firefox as my default browser. With the Multi-Account-Container addon to sandbox Google, Facebook, etc…

Adwords

As mentioned Google closed my Adwords account. And since they specifically ban you from creating another account, I can’t see any way for me to every use Adwords again. Nor recommend it to anyone else.

Photo by Goodfreephotos. Public domain

Still googling

For some services I have not found a good enough alternative or I am too lazy to switch away.

Google Maps

Google Maps is still the best mapping solution. Some alternatives are good and I try to use Apple Maps, OpenStreetMap, TomTom for some parts but still the default is to use Google Maps.

Google Docs

I have not yet found good enough alternatives to Google Docs for editing documents in a browser. Their spreadsheet and text editor is still the easiest and smoothest to use.

Whilst I have dabbled with other ad networks, Adsense is the easiest to use so I have no immediate plans to change that.

Analytics

Google Analytics is easy to use, but if I might try others soon to avoid the snapshot based data issue.

Google App

The IOS search app is actually quite good, both as a search engine but also as a news aggregator.

Regoogling myself

At the same time as I am reducing my exposure to Google I am starting to use some of their other services more.

GCP

I have in the last few years started to use Google’s Computing Platform, especially their Kubernetes based GKE. I have a few clusters on there for my own development and some live services. And might migrate more productions loads to GCP away from AWS and DigitalOcean. Though they have lately started to charge more which is an issue.

FitBit

Not sure if the acquisition is approved/complete yet but I like my FitBit Charge. Though if ever Apple releases a watch that is not square and dorky like their current ones then I could be tempted. I blame Pebble for making me wear watches again.

Nest

I love my Google Nest Mini so much we now have 3 of them. And I can see myself buying other Nest products such as the doorbell.

Google Assistant

Though not foolproof I am impressed by Google Assistant. And much prefer to use it instead of Alexa and Siri.

Google Photos

I have some very old albums from the Picasa days. But I avoided their Photos service like a plague when Google forced us to use Google Plus which I refused.

Since Google Plus is no more and Google Photos is now a standalone service it is again an alternative especially as many people I know highly recommend it.

So I plan to start migrating my albums to it. Though still duplicated in iCloud Photos and Dropbox.

To Google or not to Google

Well both.

I think I have reduced my exposure and risk. And increased back up options. But I know I still am and will be heavily reliant on Google’s services as they make great products.

Microservices are cattle not pets

2019-10-09T16:08:00+00:00

Shed no tears when quickly culling services.

I tweeted a few years ago that microservices are cattle. It is an advice I give to developers to not be precious about any microservices that they may have been involved with.

With clouds servers are cattle not pets. With microservices the services are cattle not pets. Shed no tears when quickly culling services
— Ivar Abrahamsen (@flurdy) April 17, 2016

Cattle or pets

Servers are cattle, not pets - Randy Bias

It is thought the server cattle analogy was first mentioned around 2012 by Randy Bias. Whom in turn was influenced by Bill Baker’s “Scale out not up”. Randy elaborated in 2016 a bit about the analogy’s background and history.

Pet servers

In essence in earlier times with co-located servers you knew each of the servers’ names, maybe even had a charming naming policy, and you would be upset if something happened to them. You maintained and fixed each server over a long period of time.

I.e. a pet.

Photo by Katlene Niven. CC by

Cattle servers

However if in a modern cloud virtual environment where you scale out horizontally, massively, you would not really care if mail-server-238 had an issue. You would simple mercy kill it and instead add a few more instance nodes in seconds. And not be upset by it at all, it is just work.

I.e. cattle.

And this would possibly be automatic so to you it may merely be a minor datapoint in your monthly cloud usage report.

Photo by AFP

Monolithic pets

As with servers, larges applications and services, often described as monoliths, are treated as pets.

Teams defend it and tinker with it for years. They polish it, they care for it and do not ever want to give it up. They extend it, morph it, modernise it, and add more and more features to it. They fix bugs, they even acknowledge problems with and work around it so the application stays alive.

I.e. a pet.

Photo by George E. Koronaios. CC by-sa

Precious microservices

Unfortunately that attitude also transcends to applications in a microservices architecture. Even more if they are not pure microservices but more mini-monoliths.

But developers still have affinity to what they create, so they may treat microservices as pets as well.

Don’t.

Photo by Jon Pinder. CC by-nc-nd

Microservices are cattle

Treat microservices as cattle. Microservices are meant to be small, easily rewritable and replaceable. And therefor easily deletable.

Do not try to resist deleting them because you put a lot of effort into it. Do not be precious about tiny bits of code. Be cold.

If not needed, do not shed a tear. Cull it, move on and iterate onwards.

Be cold to others

And treat code and microservices written by others with the same ruthlessness. Sure, talk and ask others before deleting it, but do not save any gunpowder. Kill any services that are superfluous.

And if others delete a service you worked on a lot, be magnanimous and supportive.

License unknown

Not clones

A difference however between microservices and cloud based servers is that servers are numerous horizontal clones, whilst microservices are numerous but individual services.

So there is not a order-48 service, but perhaps a receive-order, retrieve-order, cancel_order service or however you split and define, and name your services and context.

Photo by University of Nottingham

Don’t morph, kill & replace

If suddenly your team realised that they no longer need to get an order directly but they instead need to search for orders, don’t hesitate to delete retrieve_order and launch a new search-for-orders service.

No need to make it temporarily do two things, and 2 years down the line, after lots of iterations, retrieve_order now also makes coffee.

And no need to keep retrieve_order around just in case. Sure, the source code may exist as e.g. an archived Github project for instance, but get rid of all infrastructure immediately.

Great herder & gardner

If you keep trimming, deleting and keeping only the bare essential microservices, your project, architecture and infrastructure has a much better chance of being a solid, evolving and successful product for years.

Photo by Malcolm Morley. Public domain

All the eggs in one basket

2019-06-18T01:01:00+00:00

Many companies have all or most of their infrastructure with just one cloud provider. That does have some benefits, but also some drawbacks and serious risks.

What are these benefits of using only one cloud provider?
What are the reasons people end up with just one cloud?
What are the risks and drawbacks of putting all your eggs in one cloud basket?
And what are the alternatives and steps to reduce the risk?

All in the cloud

Since Amazon’s AWS was launched, followed by Google’s GCP, Digital Ocean, Microsoft’s Azure, Heroku and many, many more, the term cloud has become a common well understood term for hosting infrastructure.

And from initially being a bit hesitant and just trying it out many companies have now moved most of their infrastructure to the cloud. Especially younger smaller companies with less legacy datacentre usage.

Starting a new company or project using co-location datacentre servers just does not make sense any more unless you are on a real shoestring budget where the flexibility and speed of a cloud solution is not possible.

Stay with the one cloud

AWS was the first real cloud provider. There was others before depending on how you define cloud but none came with the size, marketing, and total IAAS solution of AWS. So AWS was the first provider most people dabbled with. And by now 10+ years later it is the giant in this marketplace with as many customers as all the others combined. And with a huge range of features to confuse the best of us.

And since companies was already on AWS many have not really looked further at other cloud providers.

The same happens with newer companies and projects that perhaps choose other big providers such as GCP or Azure. Once they are on and it works they do not look further as their chosen cloud provider does everything they need.

If you only use one provider your employees can specialise and enhance their skills of its specific features.

Cloud lock-in

The cloud providers also encourage people not to look elsewhere. As mentioned they provide a lot of IAAS features and continually add more so your requirements are mostly met on the one platform.

They provider services that are unique to their platform. Such as AWS’s Lamda or GCP’s Cloud Functions Or database solutions and data that are not easily transferrable such as Dynamo or Cloud Spanner.

But mostly they try to spread as wide as possible and ingrate as deep as possible into your whole organisation and procedures so that a migration elsewhere will be very painful and just not feasible.

Painting by Jean Baptiste. Public Domain

Smashed eggs

Having all your eggs in one basket is risky.

If all your infrastructure is in the cloud and with just one provider you run the risk of several things crippling your project or whole company.

Runaway usage equals costs

Setting up and using a cloud service is fast, easy and very contagious.

The old way of rack based bare metal co-location flow of ordering a new server then setting it up was time consuming, very time consuming, perhaps days if not weeks. A cloud instance is matter of minutes or less.

Virtual server solutions, e.g. Zen, VMWare, made this process quicker, but still painful and people were frugal with how often they created a new server.

With cloud solutions they are not, and they expand to use more and more storage, databases, queues, and more that are metred costs. When this infects your whole business the usage continues to escalate enormously, control and oversight evaporates and the costs rocket.

Downtime

A big risk that bleeds money is downtime. When your service is offline you loose money. A lot of money.

And big cloud providers do go down, taking your services with them offline.

AWS has had issues many times, GCP has been offline, and Azure is also known for significant downtime.

Some times it is not just a partial outage nor limited to a region, sometimes everything goes offline. For example GCP’s recent massive outage that took also down Google’s own Youtube, GMail and more.

And when they are down there is not much you can do than wait. Hopefully they are good at communicating the status.

Automated suspensions and collateral damage

The large cloud providers due to their scale has mostly automated a lot of their procedures. Including detection of illegal activity, abuse reporting and support. And at best have staff on low pay whom have to process a huge amount of tickets by spending as little time on per ticket as possible.

I have been scared by numerous reports of random accounts being frozen and service taken offline for no apparent reason. Or tiny misinterpretations that would have been corrected have they been able to talk to a human.

But I was suffering from Niemöller’s quote: “First they came for the socialists, and I did not speak out — because I was not a socialist…” I did not think I was doing anything wrong so this did not involve me.

Until last year, when my own Adwords account was suspended then banned for no apparent reason with no recourse. Thankfully they did not suspend any of my other accounts or use of other Google services as that would affect not just me badly but my family as well.

Google have done that to others, e.g. suspended all accounts linked and just suspected of being linked, including business and personal accounts. And total ban ie deleting docs, email, photos, Android profiles for all these accounts. They do state that they may do so in their policies.

Recently Digital Ocean had some bad PR when one their automated abuse script banned a persons account effectively taking his whole company offline. What made it worse he no longer could access his database backups as they were all hosted with DO. So his company was effectively dead. Thankfully he had enough social media clout to reach one of DO’s founders whom rectified the problem. Most people don’t have that reach.

These stories have made me very wary of ever relying on one provider again.

Photo by Artem Beliaikin. Public domain

Better egg distribution

So what steps can we take to minimise the risk of depending on a single cloud provider?

Cost monitoring

You should keep a close look on how much your company is spending on a cloud. And if steps need to be taken to reduce it or just slow it down, or detect any anomalies.

The providers offer monitoring, e.g. CloudWatch and StackDriver.

And there is a vast range of 3rd party tools to monitor usage, threats, errors and billing costs across several cloud providers. Such as Dynatrace, Looker, Datadog, NewRelic, Cloudability, AlertLogic, CloudHealth etc.

Though to me they all seems one tiny AWS feature announcement away from going out of business.

But its a lucrative marked and Looker was just acquired by Google.

Availability zones and regions

Most of the cloud provider downtimes are due to a single datacentre of theirs going offline for some reason. Power cut, builders accidentally digging through a cable outside, etc. So only customers using that single datacentre are affected.

So the cloud providers all offer availability zones and multiple regions to mitigate this risk.

Availability zones are multiple datacentres in the same city but not the same building. Which reduces the risk of a physical problem at a single building.

Regions are datacentre locations spread across the globe. With possibly its own multiple availability zones per site. This reduces the risk of a larger city wide problem.

If you modify and design your applications and infrastructure to spread horizontally across the zones and/or regions, you can survive when a providers single datacentre goes down.

This horizontally scalable design costs a lot architecture and development time and runtime resources so there is a clear overhead. But you can sleep more easily.

However as mentioned if there is a problem with some specific cloud features it may take down all the zones and global regions of that provider. They are rare but they do happen.

Many different baskets, hybrid

Of course the obvious solution to one basket is many baskets. Use several cloud providers, and your own hosted solutions.

This is a hybrid solution, and many providers and 3rd parties offering solutions for this. AWS offer an integration with VMWare for an on-premises solution, Outpost, that integrates with AWS. Google is offering several tools to manage Hybrid solutions, e.g. (Anthos). But I am suspicious of these, I am not sure what the motives are for their offering, but I am sure it is to drive more use of their own cloud.

Some 3rd parties offer a layer on top that is supposed to smoothly uses different cloud providers underneath. That may work, but I am also not sold on the idea of introducing yet another component. Those I have used are OK but just added more ambiguity and less flexibility.

You can architect your applications yourself to cater to work across multiple cloud providers. This is the best solution if a full hybrid solution is desired.

You really have to consider eventual consistence and temporary separated and then rejoined clusters. My take is to only do this if you have a big budget, a mature product, and very skilled architecture and ops teams. Most of the time this is a complete overkill.

Independent technology

My main opinion on hardened cloud usage is to use independent technology. Use technology stacks that you can use on any cloud provider. And minimise proprietary technology a cloud provider supplies.

For instance using Kubernetes lets you deploy your solution to many providers. You can run it across their instances, or use their managed services such as EKS, GKE, AKS and with DigitalOcean. Though Kubernetes is a behemoth and not right for everyone.

For databases use Postgres, Redis, Cassandra, CockroachDB and others that you can use on any provider and does not tie your data to a specific supplier.

Use EKL logging so that it is ambiguous if you use AWS or GCP or others.

There are also many generic serverless functions solutions. Serverless, Fission, OpenFAAS, and I am sure many more to come. I have not tested them well enough to know if they are mature enough yet.

To avoid reinventing the wheel, and use the cloud providers automatic scaling ability, I understand people choosing the cloud providers databases and streaming solutions instead of setting up and maintaining all that infrastructure yourself. My projects have often relied on DynamoDB or AWS’s RDS, and I would consider AWS’s Kafka service in future projects. So my suggestion is not 100% gospel, just be pragmatic and responsible.

Back up for total dataloss

Always have full back up of your data, and fully restore tested, that is not only stored on your cloud provider.

It does not have to be real time slave of the data but a fairly recent full back up. So that in case of total dataloss that may happen if your account is hacked, your account is suspended, or other issues, you can still restore your database to a fairly recent state.

That way your company and project is not dead, just very set back.

Photo by darf_nicht_mehr_hochladen from Pixabay. Public Domain

My fried eggs

So what do I actually suggest for companies cloud strategy?

Plan, plan, try, plan, plan.

Be aware of the risks of relying on one provider
Plan for sudden migration
Implement full back up procedures
Test out other providers
Use mostly independent technologies

Essentially plan and document a migration. But you don’t always have to implement a full hybrid solution as that can be expensive.

But do try out other providers. Perhaps run small quite independent applications on GCP if your main stack is on AWS for example. That way the ramp up and teething problems of using another provider can be dealt with already if a migration is needed.

Do trial run migration if you want to wash out any possible hidden gotchas on your reliance of the current provider.

And run as much of an independent technology stack as possible.

You can and perhaps should use their very scalable database and streaming solutions for any high throughput parts of your architecture. But do back it up and have tested migration plan to another solution in place.

Feel free to try out Lamda and similar services, but try to limit its core importance. I.e. can it be replaced quickly.

Budget cloud independence

An important step often missed by plans to move to a cloud provider is to include a budget to move away from it.

I know it sounds like a hard sell to your CTO that you are already thinking of moving away from the shiny chosen cloud provider, but it is essential in a costing plan of a bid/project that you will have to consider moving away from it as well.

But I am softening up on this requirement to instead include budgets to plan a migration and test other providers, and not budget for a full migration.

Photo by sheilapic76. CC-by

Any basket is better than broken eggs

Should all companies running on only one cloud provider follow my advice?

No, for most putting all eggs in one basket is calculated risk worth taking.

After all, A cloud provider is better than none.

And remember the big providers are much better at reliability, fault tolerance and networking than you. Yes, a lot better.

Just please consider my suggestion of planning and testing alternatives if you can afford it. Or rather can you afford not to?

To PAAS or not to PAAS

2019-04-07T21:22:00+00:00

When is a PAAS the right tool?

Who should use it? Who should not?
Who can afford it? For whom is it too expensive?
Who will benefit? Where will it be restrictive?
and When?

I have read, heard and seen many tales and blog posts on how to move away from a PAAS. But those are just information on how to and not why. And they were suitable for that organisation for their requirements at that specific time, not always.

I hope to clarify that a PAAS is great for many people/companies. And sometimes not.

What is a PAAS

PAAS = Platform As A Service.

It is a service where you deploy and host your application without having to consider any infrastructure.

You do not need to think about creating or setting up a server instance(s).
You do not need to consider any storage or networking.
You do not need to worry about OS updates and security patches.
You do not need to configure load balancing.
And much much more.

Well known PAASes are Heroku, AppEngine and AWS Lightsail. As well as many more specific tailored towards a niche, for example programming languages such as Ruby, etc.

Unlike a vanilla cloud offering i.e. an IAAS, Infrastructure As A Service, where you do have to consider all these steps yourself. Well known IAASes are AWS EC2, GCP and Azure.

There are also many ways you can host a PAAS yourself on your own IAAS or bare metal servers. Such as Cloud Foundry, OpenShift or Dokku.

Why not PAAS

Why are people complaining of PAAS offerings?

Some complaints are valid, many invalid.

Cost
Inflexibility
Ownership

The lack of flexibility is what developers and operations would moan about PAAS. People like to tinker and be in control. Connect this app to that database. Triple the memory on that instance, scale that application to 4 nodes, bundle these three apps on one instance, restrict the firewall on these etc.

The cost is what whomever pays the bill would moan about the most. If handled incorrectly a PAAS can be costly, especially if naïvely compared to pure hosting costs of an IAAS.

Ownership. People may think with the inflexibility and black-box nature of a PAAS, that they don’t know what is going on. Who can see my company’s data, my users’ requests? Is there a legal risk?

PAAS is just hosting, right?

Often people think of PAAS as a straight swap of the instances in a standard cloud offering (IAAS). And compare the costs and flexibility of that only. But a PAAS is so much more, and that is why it costs so much more per instance.

A PAAS offers logging, metrics, backup, load balancing, redundancy, roll-back, deployment, scaling, patching, etc, as part of the one price offering.

It offers years of experience, tweaking, to make the services that provide all that to work as smooth as possible, all the time, for everyone.

And when there is a network issue they take care of it immediately. Any hardware issue they take care of it. Any security patches - they apply it for you. Most of the time you wont even notice as they bring up another horizontal node of your application and replace your current one without any downtime.

And for instance in the case of Heroku they offer lots of add-ons that is mostly just one click or one CLI command away to be set up and working straight away with your applications.

Time is money

With a self hosted IAAS solution on a cloud provider, you have to pay for all the time, i.e. salaries, for people to investigate, set up, fail, retry, manage, maintain, upgrade and more of all your server instances and applications. Every time. All the time.

That is expensive.

And to be on-call when it all falls over in the middle of the night.

Is PAAS expensive?

For businesses prices at for example Heroku start at $25 per month.

That is cheap.

Some will counter that you can get a nano instance at AWS for a month for a lot less. But they forget the above mentioned, PAAS is not just hosting.

For a company $25 per month is nothing. The more powerful options at $50 or even $250 for a real business is still nothing, even if horizontally scaled to multiple nodes, if the applications are important to the company.

Remember you are comparing it to paying for more salaries in a custom infrastructure. Or divert focus away from other tasks for your Operations staff.

Remember $25 cost would comparably pay for perhaps 20 minutes or less for an Ops contractor when comparing hourly contractor rates if in e.g. London.

So no, PAAS is cheap, not expensive.

However once you scale to a lot of apps and nodes, and a lot of traffic on AppEngine for example, PAAS is then no longer the most economical solution. Though at that scale, nothing is cheap.

Premature optimisation

One thing a PAAS is good for is to prove whether a project/application need heavy infrastructure investment before you commit to it.

Try lots of ideas, pivots, applications in a live environment before focussing on one that will succeed.

Prove that it is useful and will be worth the return of investment before spending time and money into salaries, tools and IAAS to set up an infrastructure that scales for a big success.

Validate the idea, not infrastructure that may not be needed.

One size fits no-one

The requirements, time and money available is very different depending on your situation:

Startup

A Startup is often a good candidate for a PAAS project.

A Startup may want to focus on validating the idea, avoiding the above mention premature optimisation. Often they have limited budget and need to focus on a few areas only, of which infrastructure probably is not yet included.

A Startup is often time poor, needing to get something launched before anyone else do the same.

If the product starts to make profit then they can start to diversify the PAAS into custom infrastructure architecture(s).

Unicorn Startup

A Startup with big investments and in the process of massively scaling its staff may be able to hire a boat load of Operations employees to create an elaborate architecture and infrastructure.

No Ops/DevOps

If you are a small company that do not want to hire Operations staff then having your application / website on a PAAS makes sense, they do the majority of the Ops for you.

Cheap labour cost

In a cheaper labour location your company may see benefits in paying salaries to set up and maintain a custom infrastructure, as a PAAS is then probably not an economical choice.

New greenfield project

A new greenfield project in a larger organisation often have both the funding and time to go full wack on custom infrastructure.

Prototyping

Prototyping is an ideal PAAS candidate.

For some it is very useful as just a simple UX scaffold to demonstrate a project idea. For others it would make sense as a way of iterating over a full version but still not properly launched.

Live ASAP

If you need the get a live version straight away, it may make sense to deploy it to a PAAS first. Then iterate on a more elaborate custom infrastructure whilst you already at the same have a live site.

Monolith

If the app is a fairly self contained monolithic application a PAAS can be a good option.

Microservices

An ant farm myriad of a microservices architecture would be a bad choice for a PAAS.

Support tools

Simple internal tools may also be a good PAAS candidate. They often don’t require the full customer facing capacity and reliability.

Offshoot / Skunkworks

If there is a project or department that is separated from the rest you may not want it to run on your normal hosting solution. For those a PAAS might make sense. And later be rolled into the corporate infrastructure if the project itself becomes integrated.

Personal project

A PAAS is ideal for hobby projects. Something that normally can be on one node, with few visitors, and low resource requirements. It may have a database but that is about it.

And many PAAS providers such as Heroku offers free hosting for low usage applications.

Lost of personal projects

However if you have a lot of personal projects, and over time you will, you will exceed some free band restrictions with some PAAS providers.

For instance Heroku offers 1000 free hours, across all your applications combined.

And whilst most of your inactive apps will sleep often, with enough apps, especially if some are hit often by e.g. Google search bots, then you will quickly exceed that limit.

Then you will have to like me move some of the apps to another solution.

Search ranking with free pricing

Note if you use a PAAS providers free offering which uses a sleep feature, then you will experience slow response times when a request awakes it.

This affects search rankings, and user experience.

Resource demanding application

If your application demands a lot of processing power, or memory then a PAAS might not be suitable.

PAASes often provides a limited node for free. E.g. 512mb with Heroku. And then offer more powerful nodes at a much higher price point.

Core business

If the application is your core business, and you are making a profit, then perhaps you should scale it out and invest in a custom infrastructure that perfectly suits your bespoke needs.

What about Kubernetes

Kubernetes, is the current big pink elephant in the room. The 300 pound gorilla. Whichever analogy I can wrongly apply, Kubernetes is very popular at the moment and relevant to a PAAS consideration.

I am a heavy Kubernetes user myself. I have written some introduction to Kubernetes docs on flurdy.com that may be helpful.

Kubernetes bridges some of the gap between a pure IAAS and a PAAS. But it still requires significant time investment in training, configuration and normal operations monitoring and maintenance. And Kubernetes is very expensive as you end up running quite a few high memory nodes, with extra load balancers etc.

Kubernetes is vast and complicated, with a large surface area of where it could go wrong. So it is not suitable for all, in every situation, all the time.

So, to PAAS or not to PAAS?

It depends.

For a new project I would suggest just to initially throw it up on a PAAS. And not the free options, a proper supported business node.

Validate it, iterate, then if it makes sense due to popularity or company policy move it to a custom infrastructure. And for that I would suggest Kubernetes.

For any prototyping, just use a PAAS.

For a large project I would suggest Kubernetes if you do not need to go live immediately. Especially if it ends up as multiple applications.