18

I'm curious about a matrix like comparison on security/ease of management/forensic ability for each type of server. I may forget some more key features of each type also.

I've a general idea about the types but a reference matrix would be of help when choosing between them on some cases (when the automation become complex for the application for example).

To avoid concern about it being too broad, I feel that splitting it in multiples question would scatter the information and that a question about security comparison would need to compare each type also.

Improve this question

3 Answers 3

Reset to default
17

The term Phoenix Server was coined by a fellow of Martin Fowler, and all three terms described in short articles on Martin's bliki.

The pros and cons of each such server are described in the articles. The main difference being in the way the server is managed.

Servers exist to fulfill the role of a container for some application(s). Since applications change often, it is often required to change some attributes of the container - such as packages, configuration, etc. It is also sometimes required to change attributes of the container itself because of external reasons, such as security vulnerabilities that require patches to be installed.

There are several ways to change an existing server:

  1. Manually create the server initially, then keep changing its content (mutating) each time a change is required.
  2. "Bake" an image for a server based on a recipe, usually in an automated way (not manually). Then create servers from that image. And repeat this process on every change.

The former is called Snowflake, while the latter is a practice that allows Phoenix and Immutable server types. Where Immutable states that no changes are made to an existing server once it was created, and Phoenix means that a server is destroyed completely and a new one is used to replace it during the change process.

Improve this answer
3
  • If you create an image in fact it would be immutable, not phoenix, phoenix will run configurations against nodes, looking for configuration states.
    – Renato Prado
    Commented Nov 15, 2022 at 19:48
  • It depends on which way you chose to use, way #1 or way #2. In both you create an image, but after it is created the usage of that image is different.
    – Evgeny Zislis
    Commented Nov 15, 2022 at 23:45
  • But ansible for example would be used as a phoenix server and it doesn´t create an image, we don´t consider it a manually change, right?
    – Renato Prado
    Commented Nov 16, 2022 at 12:48
10

As I was more thinking of a listing of advantages and drawbacks of each type, here's is my view (not exhaustive, it's the important operational ones in my opinion):

  1. Snowflakes Servers

    • What they are: Systems with their specific configuration, no other servers in the data centre have the exact same parameters. They are usually manually administered.

    • Advantages:

      • Fitted to the needs of what's running on them.
      • Long-lived, updates are usually shorts.
      • Adapted to special cases where the tweaks are well documented by the product hosted.

    • Drawbacks:

      • Sometimes updates leave unused files, the cleanup could be complex.
      • When the changes have to be made to multiples machines it takes a while.
      • Nothing prevents undocumented change.
      • In the case of corruption, you have to rebuild a base OS and restore, some OS tweaks can't be restored and should be reapplied, it's easy to slip over a line and forget an important tweak.
      • Usually long to provision due to the manual configuration.

  2. Phoenix Servers

    • What they are: Automatically configured by some code.

    • Advantages:

      • Defined by code, version-able.
      • Easily replicated to a point in time.
      • Long-lived, short updates also.
      • Changes to controlled files are documented and can't be forgotten.

    • Drawbacks:

    • Sometimes updates leave unused files, the cleanup could be complex.
    • Not everything is under code management, some tweaks by a human can be missed if not included into the automation.

  3. Immutable Servers

    • What they are:
      • Automated one-time provisioning from a master image with generally no access.

    • Advantages:

      • Defined by code, version-able.
      • Easily replicated to a point in time.
      • Reduced attack surface due to the usual removal of remote access.
      • Fixed configuration, no change can break something
      • Easily scalable 'on demand' from the master image.

    • Drawbacks:

      • They are immutable, you have to ensure you can roll an update quickly in case of a 0day flaw impacting you.
      • Not all applications fit well inside this model (Databases, for example, a complete replace on same data is not always possible, there's migration to handle).
      • Brings some new challenges for forensic analysis of crash and log management.

None of those patterns is exclusive, you have to chose the best one according to your actual need. Snowflakes bring a lot of concerns in case of recovery after a disaster so the choice is usually more between Phoenix and Immutable.

Improve this answer
2

All three are patterns of sorts, it isn't is a case of picking and choosing which to use in any specific circumstance but a case of knowing when to recognise the patterns that can help or hurt you.

Snowflake Server

A Snowflake Server is very much an anti-pattern representing the case when a server evolves in an uncontrolled manner to the point when it cannot be easily reproduced.

I have had numerous run-ins with this kind of server in production, they are fairly easy to spot as there is usually a large number of failed changes and comments such as "it [the change] worked in Development/Test/UAT/Staging".

Phoenix Servier

A Phoenix Server is more of a principal than a pattern as Martin Fowler puts it:

A server should be like a phoenix, regularly rising from the ashes.[a]

If you were to apply IT Service Management (ITSM) or ITIL language to the same situation you would likely call it an IT Service Continuity Plan or Recovery Plan:

A separate plan for each service should provide detailed procedures and step-by-step guidelines for each stage of an incident so that the Recovery Teams are able to restore the services and thereby to meet the agreed process and component RTOs.

Immutable Server

An Immutable Server or Immutable Infrastructure is the process by which we treat all deployed infrastructure, configuration and code as utterly immutable, i.e. unchanging. When we deploy anything new we spin up new infrastructure and deploy the code to this. Interestingly this mostly satisfies the needs traditionally fulfilled by Evergreening.

Notes

  • a: Martin's colleague Kornelis Sietsma came up with the term "Phoenix Server" on an internal discussion list.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.