How To Read This Book

We’ll cover the whole adoption lifecycle in three parts, from concept to development and finally into production. As you progress through the book, the chapters will go deeper into technical details. This is intentional, as we’re working to fill the many holes we’ve seen our teams and customers encounter. We’ll try to provide enough detail to lay the right theoretical foundations and point you toward the right solution, and then move on.

Feel free to read the individual parts in any order, or not at all based on your needs. We’ve designed the code and prose so that you can do so. We’ll tell you if there’s something from an earlier chapter we think you should know. For example, if you have already built and trained your Elixir team, you may find more value in the development and production lessons explored in Parts II and III. On the other hand, if you are early in your adoption journey and you are still deciding if Elixir is the right tool for you, you will likely get more mileage from the first chapters and you can revisit the production discussion once development starts.

We understand that’s not the typical experience, but we made that trade-off because each adopting developer has a different set of needs. No simplistic grouping of technologies can cover everything that needs to be said. We’re willing to take our lumps in the review process because we believe in the need for this book in the greater community.

With those bits of housekeeping done, let’s dive into the parts of the book. We’ll also highlight which parts will be of particular interest based on your individual use case.

Part I: Concept

Adoption is in part a social problem. Adopting an emerging technology means becoming a salesperson. Helping stakeholders, teammates, and potential new hires understand that our technical decisions are wise and in the best interests of the companies we serve is a critical part of the process. New languages often mean new hiring and team-building strategies. Adoption is changing habits and practices to take best advantage of our new platform. This book will give you tools to help automate those things you can and lay out experiences to help you handle the things you can’t. We’ll walk you through the discussion in three chapters:

Team Building

Building a team for an emerging language is a little different than ramping up for a well-known, established technology. We’ll tell you what we did to train and recruit talent, set expectations, and keep folks motivated. If you have an established effective team and a good handle on recruiting and training, you will probably want to skip this chapter. If you find yourself ramping up or training for a new adoption or if you’re concerned about finding talent, this chapter will help you in your efforts.

Ensuring Code Consistency

It’s easy to fall into old habits when you’re learning a new language, but that would limit the benefits you’d reap. This chapter will show you how to use automated tools to gently nudge your team toward a more beautiful idiomatic coding style. If you have a comfortable cadence and are already well versed with lexers like Credo, Elixir’s testing ecosystem, and Elixir’s documentation tools, you may not give this chapter more than a quick skim, but most developers will appreciate the concepts outlined in this chapter. You can automate many different aspects of code quality.

Legacy Systems and Dependencies

Many of the companies adopting Elixir are choosing it to replace a legacy system, and we’ll cover that topic. Dealing with legacy systems also means carefully considering each new line of code you write and each new dependency you add. Sometimes code becomes legacy because of business needs, other times because the code becomes less healthy. In this chapter we will talk about how to replace legacy systems, building tomorrow’s friendlier legacy systems as you write code today, and working with internal and external dependencies.

If you’re a manager, an executive, or a team lead tasked with building a team and establishing culture, Part I is for you. The chapters in this part will also be of interest if you are starting your own project and need to understand what tools can help you build consistent code.

When you’re through with Part I, you’ll understand how to build a unified tool that writes uniform code. You’ll then think about the best ways to think about taking that old system apart to adopt the new, should that be your chosen path.

Part II: Development

This part will show you how others have successfully built Elixir applications using new development teams or retooled teams who wrote in some other language. We’ll focus on how to write code to do things beyond what you’d find in most typical technology books. We’ll focus specifically on ideas and tools we’ve found difficult to find elsewhere. In particular, we’ve divided this part into the following chapters:

Making the Functional Transition

Object-oriented developers sometimes have trouble learning functional languages. This chapter gives advice to help make that transition. It is tailored specifically for beginning and intermediate Elixir developers, especially those who have come from other ecosystems.

Distributed Elixir

Adopting a new language is hard enough when you’re only concerned about one system. It takes experience to learn to split concepts across the wire. This chapter provides exactly that. We’ll talk about how to name things, the role of OTP, and how to think about distribution. If you’re a technical lead or looking to break Elixir out of a single box, this chapter will help you reason about the next level of challenges you’re likely to face.

Integrating with External Code

Sometimes, Elixir is not enough. When your code needs to step out of its universe, Erlang and Elixir provide several tools to do exactly that. This chapter covers those tools, whether you decide to stay in the same memory space, or use different processes or different machines altogether. If you plan to stay within the Elixir ecosystem for all of your application needs, you’ll likely want to skip this chapter. Just give it a quick skim so you’ll know the techniques available to you should the need arise.

If you’re a new Elixir developer making the transition from OOP to FP, the early chapters in this part will help. If you’re an experienced developer but struggling with what it means to write a distributed project or the approaches to integrating external code, the later chapters in this part will have something you find useful.

When you’ve completed Part II, you’ll have more tools to think about the things that trip up early adopters from functional programming to concurrency, even distributed systems. Then, in the final part, we’ll worry about deployment.

Part III: Production

Every new language community has to work out what to do with deployment. Elixir is no different. It’s not surprising that one of the most common questions Plataformatec received was how to deploy, and how to monitor the system once deployed. This part of the book will point to some prevailing wisdom in these areas. In particular, you’ll see chapters for:

Coordinating Deployments

Deploying a simple system on a single server is a pretty easy problem, but modern applications no longer fit that profile. This chapter will show how successful DevOps folks think about releases and the tools they use to deploy. In some teams, the folks that write the code are the same ones that deploy and support it in production. If you’re involved in any way in deploying Elixir or packaging your code for deployment, this chapter is for you.

Metrics and Performance Expectations

Typically, new languages have some lesser-utilized areas with less documentation than others. Since performance measurements often happen after production applications are close to ready, this topic is one of the last to develop. When it’s time to push Elixir to the limits and test performance, you’ll need to know how to measure your performance and report those results. This chapter will tell you what you need to know. The techniques are advanced and the topics specialized, so you’ll want your Elixir foundations to be pretty solid to attack this material.

Making Your App Production Ready

Once a system reaches deployment, the debugging and monitoring tools change. That throws many developers off, but Elixir has some unique capabilities that greatly simplify this process. This chapter will focus on instrumenting, measuring, and monitoring production systems. Just about all developers need to know about the debugging, logging, and reporting techniques in this chapter.

If you’re in operations or responsible for seeing that your application is easy to deploy and manage, this part will be invaluable to you. Leads and architects will also want to understand how the deployment story fits together.

When you’ve finished this part, you’ll know how others deploy with confidence. You’ll learn what to measure, how to instrument your code, and how to monitor for the best possible reliability and information.