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
- LAN Gaming using Windows 98 machines
- Connect back to home network to avoid region blockinghttps://github.com/n42n/n3n
- https://github.com/n42n/n3n
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)
- Use Open tools and approaches
- Define your SOE
- Not just your OS