Spotlight: Ellie Fairholm and Josep (Pep) Giralt D'Lacoste (Authors) Interview and AMA!

Democratizing Deployment
with Ellie and Pep
@elliefairholm and @Gilacost

spotlightaug24

Ellie Fairholm and Josep (Pep) Giralt D’Lacoste are on a mission to democratize the process of software deployment and encourage development teams to “fail fast.”

We spoke with Ellie and Pep about their new book for BEAM developers on how to combine development and operations with the goal of creating a frictionless team that delivers frequent small releases.

Engineering Elixir Applications: Navigate Each Stage of Software Delivery with Confidence by Ellie Fairholm and Josep Giralt D’Lacoste

INTERVIEW

Watch to the complete interview here:


WIN!

We’re giving away one of Ellie and Pep’s books to one lucky winner! Simply post a comment or a question in his ask me anything (AMA) below, and the Devtalk bot will randomly pick a winner at a time of the author’s choosing…then automatically update this thread with the results!


Interview Highlights

For those who prefer to read rather than watch or listen, following are highlights from the interview.

On shared responsibility…

The DevOps approach that Ellie and Pep advocate combines continuous integration, delivery, and deployment in a pattern of source, build, test, and deploy. It also has a tendency to democratize software development and build happy teams. There are many compelling reasons to move to a CI/CD pipeline. “If you’ve Dockerized everything, people can quickly spin up the app. You can deploy faster. Ship features faster even if new people come in.” says Ellie.

“If you submit a pull request to the main branch and it’s automatically deployed, you know—everyone knows—that it’s going to be deployed, so everyone is going to be more careful,” Pep muses. If teams can shift towards CI/CD, deployments become routine and manageable. “And then you have healthier teams and there’s more love in the environment because knowledge is shared, problems are shared, and we all take care of each other.”

“Sharing responsibilities, it creates a lot more empathy across teams. It makes teams work, I think, better and more efficiently.” Ellie postulates.

When the documentation is the code you can “let the code base be the source of truth of everything. If you have continuous delivery, you don’t need to ask anyone how the application is deployed,” explains Pep, “just go to the Github workflow…and see how it’s deployed.”

On environment integrity…

Differences in development and production environments often mean bugs in production that can’t be reproduced locally. “Hopefully, [those issues] will be a thing of the past.” says Ellie. “One of the big things that we talk about is environment integrity…using the same tools for development and production. So …you can replicate all production scenarios in development.”

For example, with Docker Swarm, you can use the Docker Compose file for both development and production. One of the downsides is that it’s easy to lock yourself into particular versions of libraries and everything else. Ellie and Pep use tools like Renovate that regularly check your dependencies and submit pull requests to update those dependencies.

On visualizing infrastructure…

Engineering Elixir Applications offers much more than just the practical steps to deliver BEAM applications using a DevOps approach. The authors developed an application for the book that visualizes infrastructure operations. They built a Phoenix LiveView application that “allows you to visualize the different nodes in which availability zones they are deployed. It allows you to see the CPU usage. And then it allows you also to stress the cluster and see the different auto-scaling activities.”

Visualization makes the process much less abstract and more tangible to developers who may not be experienced with deployment-related tasks and information. And while the book uses the BEAM ecosystem for examples, principles like CI/CD, shared responsibility, environment integrity, and Kaizen are universal. For example, no matter the framework, tools, or language, submitting something small frequently and then testing it offers benefits. “You aim small, you fail small.” Pep reminds us.

On writing together…

The couple met while working at the same company six years ago, where they realized they shared a passion for improving deployment practices. And now they are writing a book together about deploying software, which has the potential to be quite stressful.

But just as they automate away friction points to make teams a happier place to be, they automate away some of the pain points of writing together.

“We have our own CDI pipeline for the book, for each chapter, checking all the code in each chapter to make sure it works.” Ellie explains.

They wanted to reproduce the whole infrastructure that was being built in each of the chapters, but decided to do the minimum. “For example, if we have a Terraform module, let’s try to validate, check the format…and try to at least plan the Terraform but not apply it.” says Pep.

Ellie and Pep are able to communicate openly without ego to avoid conflict and make writing a book together a happy experience.

Dave Thomas asks if they guarantee that if you follow CI/CD practices you’ll find love. “Yes, that should be our marketing tagline,” Ellie says, laughing. “Everyone should be in love with each other.” Pep adds with a grin.


Now that you know their story, add Ellie and Pep’s book to your developer toolkit today! Don’t forget you can get 35 percent off with the coupon code devtalk.com!

Engineering Elixir Applications
book-engineering-elixir-applications


Follow the authors:

Ellie Fairholm

Josep Giralt D’Lacoste


YOUR TURN!

We’re now opening up the thread for your questions! Ask Ellie and Pep anything! Please keep it clean and don’t forget: by participating you automatically enter the competition to win one of Ellie and Pep’s ebooks!

3 Likes

Great interview and it’s nice to see video interviews making a return (and nice to see Dave in them!) :smiley:

3 Likes

Hi everyone! It was a great to chat to Dave about our writing process and the main ideas behind the book. If anyone has any questions/comments we’d love to hear them :slight_smile:

2 Likes

Such a charming interview, but also packed with good info for Elixir and BEAM programmers. I agree that adding the video component back was a good move.

2 Likes

Wow! I loved the interview. It seems like this book is an excellent addition to the Elixir learning resources. It’s great that the interview was conducted by Dave Thomas. This book looks like a must-have for every Phoenix developer!

2 Likes

I watched the interview again. I like how humble they are. Their humility and passion for their work are truly inspiring. This book seems like an invaluable resource for Phoenix developers who are interested in enhancing their DevOps practices.

Personally, I find watching the interview as a video much more engaging than reading it as text.

4 Likes

@elliefairholm

Nice interview and this seems like a very interesting book

My question to the author, is around Dynamic vs Static languages

How do you think Engineering an application written in Dynamic language could different from Static language

Also noting that Elixir is adding a type system how could this impact Engineering Elixir Apps in the future?

3 Likes

@shishini good question! We don’t really think that engineering/deploying an application that written in a dynamic language will be that different from a static language. The difference between dynamic/static languages can be most seen at development and building time. The packaging of the application will depend on the language being used and you may see more errors when packaging an app for a static language, but once the application is packaged, the actual deployment won’t change much.

As for how bringing typing into Elixir will change how we engineer/deploy them, the same rule applies really. It’ll make a difference when developing/building the app, but the deployment steps won’t change.

One thing we would say is that even though there will be types, this shouldn’t be a replacement for testing our apps as types aren’t a sliver bullet :slight_smile:

3 Likes

Actually I am often skeptical if Elixir really needs something like Docker or K8s.

BEAM and Erlang VM offer very good similar features.
Like Ruby on Rails, it looks like for medium sized applications, those set up are really complicated and overkilled.

2 Likes

I don’t have any questions but I’d like to say that I have my eye on this book and can’t wait for it to be released! :slight_smile:

3 Likes

hi @adamaiken89 , thanks for the comment. What makes you skeptical of using Docker/K8s with Elixir? For us, they’re not mutually exclusive and both offer different advantages that can have benefits when used together.

3 Likes

Hi @Mikael, thanks for the comment! We don’t think really believe that “people trusting CI/CD too much and deploying broken artifacts” is a bad thing. Enabling CI/CD changes your mindset and forces you to be more careful. Knowing that your code is going to be deployed automatically makes you more cautious about the quality of your code. And if you put the right healthchecks in place, you can always ensure that the minimal core requirements for your application are met for any new features. If (and when) bugs do make their way to production, it’s a good idea to think about the way the PR revision was done, or if tests where written for the feature. Also, we would not make the distinction between developers and ops. CI/CD bridges that gap and makes the team more cohesive, so if something goes wrong all the team (developers and ops) should sit together and try to put something in place to avoid the issue in the future.

3 Likes

@elliefairholm and @Gilacost

Great, my question is can you build an umbrella application with this approach?

2 Likes

@elliefairholm and @Gilacost

What’s one change every team could make right now to improve deployment health?

2 Likes

@elliefairholm and @Gilacost

This book has a quite long list in “What You Need”.
Are those tools/services all free or how much money will I have to spend to be able to follow along the book? I guess at least for the AWS services I will need to pay.

1 Like

Hi @code-of-kai, thanks for the question! We think there are 2 things that all teams should do. The first is implementing a continuous deployment pipeline as it will reduce the feedback loop. This will not only help you catch (and solve) bugs quicker, but it will improve a team’s development speed, health, and confidence. The second is implementing automatic rollbacks based on health checks.

2 Likes

@Nefcairon we’re glad you asked this. All of the tools are free to use. We walk you through how you can install them all in Chapter 1. As for paying AWS, you shouldn’t have to pay while implementing the infrastructure of the book as the type of instances that you’ll launch is part of the free tier that AWS offers for one year after you create your AWS account. But if you were to get charged (because you left your infrastructure running for a long time), the amount you would have to pay should be minimal as you’ll only pay for the time that your storage is above 30GB.

3 Likes

Good question! Yes, you can definitely use our BEAMOps approach with an umbrella project. However, creating the releases for each app might be a bit more complicated. The default Dockerfile created by the Phoenix release generator is for non umbrella projects. So if you were using the umbrella structure, but building your application as a single artifact, then you can follow the steps in the book as they are, tweaking the Dockerfile to copy the right umbrella paths. But if you are wanting to create separate releases for your different applications, you’d have to configure your Dockerfile(s) and releases in mix.exs accordingly. The principles of ownership, CI/CD pipelines, scalability, infrastructure-as-code, environment integrity, the kaizen principle etc. would still be the same though regardless of if your project is an umbrella app or not.

3 Likes

The way of BEAM is more like statefulset on K8s while nowadays K8s is treated as stateless components most of the time. They are serving very similar purpose to make the applications run properly. (cluster level vs app level)

1 Like

Installing the mentioned version of erlang gave me issues (I also tried with some other versions in 26.2…)

❯ asdf install erlang 26.2.1

ERROR: 'asdf_26.2.1' is not a kerl-managed Erlang/OTP installation.
Build 'asdf_26.2.1' has been deleted.
Extracting source code for normal build...
Building (normal) Erlang/OTP 26.2.1 (asdf_26.2.1); please wait...
Initializing (build) log file at /Users/justincalleja/.asdf/plugins/erlang/kerl-home/builds/asdf_26.2.1/otp_build_26.2.1.log.
Attempting to use Homebrew OpenSSL from /opt/homebrew/opt/openssl@3.0...
WARNING: ... you may have to brew the expected version or otherwise use --with-ssl
APPLICATIONS DISABLED (See: /Users/justincalleja/.asdf/plugins/erlang/kerl-home/builds/asdf_26.2.1/otp_build_26.2.1.log)
 * odbc           : ODBC library - link check failed

DOCUMENTATION INFORMATION (See: /Users/justincalleja/.asdf/plugins/erlang/kerl-home/builds/asdf_26.2.1/otp_build_26.2.1.log)
 * documentation  :
 *                  fop is missing.
 *                  Using fakefop to generate placeholder PDF files.

ERROR: build failed.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/in.h:657:10: fatal error: cannot open file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet6/in6.h': Too many open files
  657 | #include <netinet6/in6.h>
      |          ^
1 error generated.
make[4]: *** [obj/aarch64-apple-darwin23.6.0/opt/jit/beam_asm_module.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [opt] Error 2
make[2]: *** [opt] Error 2
make[1]: *** [jit] Error 2
make: *** [emulator] Error 2

Please see /Users/justincalleja/.asdf/plugins/erlang/kerl-home/builds/asdf_26.2.1/otp_build_26.2.1.log for full details.
Auto cleaning all artifacts except the log file...
(use KERL_AUTOCLEAN=0 to keep build on failure, if desired)
Cleaning up compilation products for 'asdf_26.2.1' under:
  - /Users/justincalleja/.asdf/plugins/erlang/kerl-home/builds...
  - /Users/justincalleja/.asdf/downloads/erlang/26.2.1...
... done.

To overcome this, I had to:
ulimit -n 4096

to increase open file limits… might have helped but I also:
❯ brew install autoconf wxmac openssl@1.1 fop

with some issue with openssl@1.1

Anyway asdf list erlang lists it now and i could install the rest with asdf install and the tools version file.