On February 24 and 25, we are giving you a chance to ask questions of PragProg authors Ellie Fairholm and Josep Giralt D’Lacoste as part of our Winter Literary Festival in partnership with codebar.
Ellie Fairholm is a full-stack developer on the path to becoming a solutions architect. She excels at communication and believes that no topic is too difficult to learn. She is deeply passionate about making technology available to all, especially to those often underrepresented in the industry. She currently lives in the UK and is committed to working on projects that will one day change the world.
Pep G. D’Lacoste is the founder of BeamOps Software Consultancy, a company that takes a hands-on approach to simplifying BEAM projects and ensuring lasting sustainability by involving the whole team. He has been working with Elixir for 10 years and helped set up the Elixir Meetup in his home town of Barcelona. He now lives in the UK and is on a mission to empower developers and revolutionize the way technical teams operate.
Ellie Fairholm and Josep Giralt D’Lacoste are the authors of Engineering Elixir Applications. Ask them about programming, DevOps, Elixir, or anything else—really!
Everyone commenting or asking a question will automatically be entered into a drawing to win one of the authors’ books.
In addition, from February 24 to March 2, as part of our Winter Literary Festival with codebar, you can use promo code 2025WinterFest to save 40 percent on purchases at pragprog.com. We’ll donate 20 percent of the net income from the promotion back to codebar after the event.
Offer not valid where prohibited or restricted. Offer not valid on previous purchases. The Pragmatic Programmer: 20th Anniversary Edition is not eligible for discounts, as we do not publish it.
Hit Reply to post your question below. The authors will check in periodically to answer your questions.
Hi Margaret, we’re currently scheduled to speak at Goatmire conference in Sweden in September it’ll be my first time in Sweden so I’m super excited. We’d love to see people there and meet anyone going! We haven’t got any other conferences in our calendar yet, but are definitely open to going to others if they align with our schedule.
I was working on a project called Abi. It’s a chatbot that gives users a chance to connect with and ask questions to real doctors around the world (although I have to admit that this project doesn’t use Elixir). Josep and I are currently working on a couple of (secret) projects though (both mobile apps that will have Elixir backends) which are exciting. One’s in the healthcare space and another is more lifestyle based. I’d love to know what you’re working on too!
Sweden, wow. Sounds like an amazing trip. The Elixir one I want to go to this year if possible is https://www.gigcityelixir.com/ --many of our authors will be there. Also, I really would love to meet Maggie and Bruce Tate in person.
The toughest challenge is always clarifying to customers that orchestration and the BEAM do not overlap. Many assume that BEAM-based systems don’t add much value when using something like Kubernetes, but that’s a misconception.
The easiest and best part has been working with Elixir itself—its development experience is fantastic. It’s also a pleasure to collaborate with Elixir developers; more often than not, we find they share our passion, and it’s always rewarding to reach that shared understanding and enthusiasm.
I’ve read through chapter 9 so far. It’s a great help to have this example of the integration of Phoenix, Containers, Swarm, Packer, Terraform, GitHub, AWS, and, it looks like, an LGTM stack. It’s complex territory, so I’m glad to have this book as a guide. You’ve done a great job on the book, as well. I’m excited about what I can build with these tools.
Hi @swrenn, thank you for such nice comments! We’re glad you’re enjoying the book and finding it useful we’re also excited to see what people end up building with these tools, hopefully we can get more Elixir apps out there!
Hi @Gilacost and @elliefairholm. I just watched your ElixirConf talk on which the book the based and found it quite insightful.
A couple of questions for you:
When introducing beamOPs to your clients for the first time, how long does it take an average for you to train the teams, migrate the project and get them to adapt this approach? Think in terms of days, weeks or months.
What was the hardest project you’ve tackled so far when introducing BeamOPs and do you have any lessons or pointers or red flags we should be aware of.
This one is for Josep. Josep, you speak very fast(in a good way of course). Have you ever considered rapping as a hobby?
That’s all from me. Thanks in advance for the replies!
Thank you for your question! I really appreciate that you enjoyed the book!
I haven’t used FLAME on AWS, and I don’t think there’s a straightforward way to implement it using native AWS resources unless you’re running a kites cluster and leveraging the FLAME kites backend.
From my perspective, Fly.io is a much better fit as a backend for FLAME because it spins up VMs extremely quickly and securely. I believe they achieve this using Firecracker under the hood, which is also what AWS uses to run Lambda functions. This backend effectively handles ephemeral VMs and provides a scalable networking layer, making it a solid choice for FLAME.
The FLAME kites backend, on the other hand, only allows you to assign resources if they are available in the node pool and can create pods, but it doesn’t offer the same level of dynamic VM provisioning.
AWS Lambda does support running Docker images, but these run in complete isolation, meaning you wouldn’t be able to connect them as distributed Erlang nodes as far as I know. Because of that, Lambda isn’t a viable option for FLAME in a distributed Elixir setup.
Thanks for watching our ElixirConf talk! We’re really glad you found it insightful. Great questions—let’s dive in.
How long does it take to train teams, migrate projects, and adapt to BEAMOps?
It depends on the team’s starting point and the complexity of their existing setup, but generally:
Training: If a team has prior infrastructure experience, we can get them comfortable with the fundamentals in a few days. If they’re new to infrastructure automation, it might take a few weeks of hands-on work.
Migration: The biggest factor is whether they’re moving from a traditional ops model (manual deployments, ad-hoc infra changes) or an existing IaC setup. In simpler cases, we’ve migrated projects in a couple of weeks. More complex cases—especially those involving multi-region setups, custom networking, or legacy constraints—can take a few months.
Adoption: The cultural shift is often the hardest part. Some teams embrace BEAMOps quickly, while others take longer to trust the automation and adjust workflows. Meaningful adoption typically happens within weeks to a few months.
Hardest project and lessons learned?
One of the toughest projects we tackled was an on-premises GitHub Actions CI/CD setup, where we had to build base images for vSphere to homogenise all environments. The hardest parts were:
Reproducibility: Ensuring builds were consistent across different environments and architectures.
Security & Compliance: The client had strict security policies, requiring careful handling of credentials, network isolation, and audit logging.
Onboarding & Knowledge Transfer: The internal team did not have strong DevOps skills, which made adoption more challenging.
Lessons learned & red flags to watch for:
Define a clear boundary between application concerns and infrastructure concerns early on. Avoid over-engineering at the start—begin with the simplest automation that delivers value. Watch out for legacy mindset resistance. Some teams struggle to let go of manual processes.
Josep, have you considered rapping?
Haha, I take that as a compliment! No rapping yet, but funnily enough, my little brother does. Here’s one of his songs if you’re curious: Spotify link.
Hope this helps! Let me know if you want to dive deeper into any of these topics.
Thanks for the detailed response to my question Josep. I’m gonna bookmark this response and keep it nearby.
Clear boundaries, avoid over-engineering and watch out for legacy mindsets. Gotcha.
Ok this one was the best part haha. I listened to Curame over and over for the past half an hour. Your brother’s got skill! It’s not too late for you to join him and form a boy band.
Define a clear boundary between application concerns and infrastructure concerns early on.
Avoid over-engineering at the start—begin with the simplest automation that delivers value.
