Developing in the open, building a product with our users by Toby Bellwood
The Lagoon Story
At amazee.io . Is Lagoon Lead
What is Lagoon
Application to Kubernetes (docker build for customer, converts to k8s)
Docker based
Based on git workflows. Mostly Drupal, WordPress, PHP and NodeJS apps
Presets for the extra stuff like monitoring etc
Why
Cause Developers are too busy to do all that extra stuff
and it means Ops prefer if it was all automated away (the right way)
8 full-time team members
Knows a lot about application, not so much about the users (apart from Amazee.io)
Users: Hosting providers, Agencies, Developers
The Adopter: Someone using it for something else, weird use cases
Agencies: Need things to go out quickly, want automation, like documentation to be good. Often will need weird technologies cause customers wants that.
Developers: Just want it stabele. Only worried about one project at at time. Often OS minded
User Mindset
Building own tools using application
Do walking tours of the system, recorded zoom session
Use developer tools
Discord, Slack, Office Hours, Events, Easy Access to the team
Balance priorities
eg stuff customers will use even those Amazee won’t use
Engaging Upstream
Try to be a good participant, What they would want their customers to be
Encourage our teams to “contribute first”. Usually works well
Empowering the Team
Contribute under your own name
Participate in communities
How to stay Open Source forever?
Widening the Core Contributor Group
Learn from others in the Community. But most companies are not open sourcing the main component of their business.
Unsuccessful CNCF Sandbox project
Presenting n3n – A simple Peer to Peer VPN by Hamish Coleman
How to compares to other VPNs?
Peer to peer
NAT piecing
Not all packets need to go via the server
Distributed ethernet switch – gives extra features
Userspace except for tuntap driver which is pretty common
Low deployment requirements, easy to install in multiple environments
Relatively simple security, not super secure
History
Based off n2n (developed by the people who did ntop)
But they changed the license in October 2023
Decided to fork into a new project
First release of n3n in April 2024
Big change was they introduced a CLA (contributor licensing agreement)
CLAs have problems
Legal document
Needs real day, contributor hostile, asymmetry of power
Can lead to surprise relicencing
Alternatives to a CLA
Preserving Git history
Developer’s Certificate of Origin
Or it could be a CLA
Handling Changes
Don’t surprise your Volunteers
Don’t ignore your Volunteers
Do discuss with you Volunteers and bring them along
Alternatives
Wireguard – No NAT piercing
OpenVPN – Mostly client to Server. Also Too configurable
Why prefer
One simple access method (Speaker uses 4x OS)
A single access method
p2p avoid latency delays because local instances to talk directly
Goals
Protocol compatibility with n2n
Don’t break user visible APIs
Incrementally clean and improve codebase
How it works now
Supernode – Central co-ordination point, public IP, Some access control, Last-resort for packet forwarding
Communities – Nodes join, form a virtual segment
IP addresses
Can just run a DHCP server inside the network
Design
Tries to create a full mesh of nodes
Multiple Supernodes for metadata
Added a few features from n2n
INI file, Help text, Tidied up the CLI options and reduced options
Tried to make the defaults work better
Built in web server
Status page, jsonRPC, Socket interfaces, Monitoring/Stats
Current State of fork
Still young. Another contributor
Only soft announced. Growing base of awareness
Plans
IPv6
Optimise encryption/compression
Improve packaging and submit to distros
Test coverage
Better NAT piercing
Continue improve config experience
Selectable tuntap drivers
Mobile phone support hoped for but probably some distance away
Speaker’s uses for software
Manage mothers computer
Management interface for various servers around the world
From the stone age to silicon: The Dwarf Axe guide to the evolution of technology by Steven Ellis
What is a “Dwarf Axe” ?
Snowflakes vs Dwarf Axes
It’s an Axe that handled down and consistently delivers a service
Both the head ( software ) and the handle ( hardware ) are maintained and upgraded separately and must be maintained. Treated like the same platform even though it is quite different from what it was originally. Delivers the same services though
Keeps a fairly similar services. Same box on a organisation diagram
Home IT
Phones handed down to family members. Often not getting security patches anymore
Enterprise IT
Systems kept long past their expected lifetime
Maintained via virtualisation
What is wrong with a Big Axe?
Too Big to Fail
Billion dollar projects fail.
Alternatives
Virtual Machines – Running on Axe somewhere,
Containers – Something big to orchestrate the containers
Microservices – Also needs orchestration
Redesign the Axe
The cloud – It’s just someone else Axe
Options
Everything as a service. 3rd party services
Re-use has an end-of-life
Modern hardware should have better )and longer) hardware support
Ephemeral Abstraction
Run anywhere
Scale out not up
Avoid single points of failure
Focus on the service (not the infra or the platform)
