DIBI - 2025 - Workshop
Introduction
Last week I attended DIBI in Edinburgh on the 5th and 6th of March 2025 which was a conference for designers and developers, with the first day for Workshops and the second day for the Conference. The first day for the Workshops started with my journey up from Gateshead to Edinburgh via Newcastle in the morning which was less than a couple of hours away by train to arrive there in plenty of time and head to the Edinburgh Marriott Hotel Holyrood which would be the venue for the Workshop and where I would be staying.
LNER Azuma to Edinburgh Waverley
Edinburgh Marriott Hotel Holyrood
Build Smarter, Scale Faster: Mastering AWS for Product Growth - Ross Cooney from Stable State
The workshop will help design right-sized AWS environments, document infrastructure effectively, scale efficiently and translate technical decisions. Stable State work with businesses to tidy up their businesses and get the best exit they can do or scale to the next step in their business journey.
Product-Centric Infrastructure design
Start with the product not the technology, user needs not service features, begin with core and expand thoughtfully and match requirements to actual product needs. How to frame tech to who are technically savvy.
The Cost of Getting it Wrong
Over-engineering costs including unnecessary spend, increased complexity and slower iteration. Under-provisioning costs, poor user experience, emergency scaling (premium costs) and missed opportunities. There is a degree to which where someone asks for a specific outcome then you can push back, you have to make some of those decisions but it is possible to have too much that you don't need.
Essential AWS Services for every product
Compute includes EC2, Lambda, Elastic Beanstalk. Storage includes S3, RDS, DynamoDB. Networking includes VPC, Route 53 and CloudFront. Security with IAM, Security Groups and WAF. You can make an Amazon Organisations which splits things across accounts, and this is free and makes it easier to group things together. You can deploy using Terraform with Infrastructure as code but if make any changes outside of this need to use drifts to make sure that this is kept up to date and gives you the flexibility to get things done. You can get an indication of what is available with LucidChart visual representation along with LucidScale.
Right-Sizing Principles
Start small but design for expansion and build for future growth in mind without overprovisioning and match instance types to workload etc.
Common MVP mistakes
Technical mistakes is for overprovisioning “just in case”, selecting wrong instance families and ignoring reserved instances. Business mistakes include no cost monitoring, missing cost allocation and inadequate budget planning. There is a lot of technical decision making that's needed to think about what it needs to run on or what is needed, need to choose the right instance for the right job. Reserved instances need commitment long term which can reduce costs but needs planning. You need not only a production environment, but you also need a development environment, but you can turn things off but for some instances like RDS these will come back on after a week. You can have a set budget for resources and need to be able to explain this from product and customer impact if this is higher.
Communicating Infrastructure Value
Available with customer satisfaction, scalability with growth readiness and performance with conversion rates and think beyond tech with product outcomes.
Build your MVP tower
Build a tower that holds the weight of a phone with spaghetti and marshmallows but there is a limited budget on materials and need to build this and it has to be the height of and hold the weight of an iPhone. This will help understand What requirements were prioritised and why, how to balance immediate needs vs future capability and what trade offs make to stay withing budget etc.
MVP Tower
Why documentation matters
Team alignment and shared understanding, knowledge transfer about preserving decisions, budgets approvals to justify investments and stakeholder support for building confidence. Need to be able to explain all the resource you need, what are the design requirements. Infrastructure as code allows you to develop and move from simple design to a more complex one, and be able to build a business case and can have future provisions that don't need to be use if the product never reaches a particular threshold.
Two Audience Problem
Technical audience needs implementation details, config specifics and technical dependencies and more. Effective visual documentation including architecture diagrams, cost breakdowns and performance metrics.
Connecting Infrastructure to Product Metrics
Page load time such as bounce rate, system availability for customer retention, database performance with transaction completion and scaling speed for handling viral moments. You can tie metrics to infrastructure decisions early on and later down the line and think about what to choose and why.
Speaking the language of finance
CapEx vs OpEx which is understanding capital expenditure vs operation expenditure in cloud contexts and could have TCO for total cost of ownership beyond just AWS bills, ROI calculations methods with approaches to quantify on infrastructure investments and payback period for determining how quickly infrastructure investments deliver returns. Take everything down again and build it back up again to see what you.
Making the Business Case
Problem is current limitations, solution is the proposed approach, benefits for expected outcomes and costs for investment required and timeline for implementation schedule.
Document & Rebuild your MVP Tower
Create dual-audience documentation with technical specifications for developers and business value expectation for stakeholders. Why did you do this and document this. There is a lot of nuance in decision making and documentation and should always go back to infrastructure and see if it is still serving the same purpose, have things moved on.
Documentation (Service == Marshmallow) - Bottom Layer Four by Five Services at Input Layer 0 for DynamoDB Database and then Four by Three Services on Layer 1 for Lambdas and then Three by Three on Layer 2 for Web Services and Two by Two on Layer 3 as Load Balancer for Top Layer.
New Tower
When to Scale your Infrastructure
Performance metrics approaching thresholds such as monitoring system indicators that signal capacity requirements. User growth projections including anticipating increased demand based on business forecasts and feature expansion plans including preparing for new capabilities that require additional resources. Seasonal demand patterns including planning for predictable fluctuations in usage. These areas can be used to scale things up and down and some businesses can have most of their sales at a specific time.
AWS Scaling Options through a Product Lens
Vertical scaling larger instances for performance-sensitive components and horizontal scaling with more instances for handling increased load, service upgrades for moving to more advanced service tiers and regional expansion with multi-region for global audiences. You need to accommodate growth and scale, what issues could be caused down the line and how do you position yourself for the future.
Auto-scaling strategies
Scheduled scaling for predictable patterns based on known time-based changes and on-demand changes allowing planned resource allocation. Predictive scaling using machine learning to forecast capacity needs before they occur and optimise resources proactively and dynamic scaling for variable demands that respond in real-time to metric thresholds, automatically adjusting to traffic fluctuations.
Reserved Capacity vs On-Demand
Business case for reserved instances for stable predicable workloads with clear growth forecasts with significant cost savings up to 72%. When to stay with on-demand for uncertain growth and experimental features and short-term projects. You can change what you use that spend on for reserved capacity can be spent on almost any resources.
Cost Optimisation Technologies
Right-sizing existing resources to match instance types to actual workload requirements, implementing auto-scaling automatically capacity to match demand, using spot instances for appropriate workloads leveraging discounted capacity for non-critical tasks, leveraging savings plans and committing to usage levels for significant discounts and implementing lifecycle policies including automatic data and resource management to reduce storage costs.
Communicate with Finance
Effective communication with finance requires strategic approach and relevant business context including focus on business metrics including revenue impact and customer retention along with market share. Present clear trade-offs with cost vs performance and risk vs opportunity. Use concrete examples with real-world success stories with numbers and how to relate to a competitive advantage and business flexibility.
Summary
For product designers infra structure questions to ask, performance considerations in design and for entrepreneurs will differ and common pitfalls can be avoided.
Conclusion
The Workshop was very informative, fun and interesting and applied equally to any cloud provider such as Azure and it was a great way to start the DIBI conference. The Workshop day ended with a Mixer at Brewdog Doghouse to meet up with fellow attendees and speakers and have a chat, and some food before heading back to the hotel ready for the Conference the next day.