Building a cloud-friendly application

These are separate questions...

The Cloud™: noun

Someone else's hard drive

Cloud computing: noun

Abstracting away physical infrastructure

Disposable application design

What makes an application
cloud-friendly?

They're not rules

They're more like guidelines

Split code from content

Your application is disposable.
Your data is not.

Data flow

You don't get an in-between option

Take-away

Cleanly separate "Dev provided" and "user provided" files

What is configuration?

Does config come from the developer or the user?

Git or Database?

Drupal Config Management

1. Configure in UI / DB
2. Export to YAML
3. Commit to Git
4. Push / Pull
5. Import back to DB

Take-away

Decide

What happens at runtime
stays at runtime

Dependency inject your environment

• DB credentials (Solr, Redis, etc.)
• API keys
• All paths on disk
• Domain names

Environment variables

          // PHP
          getenv('foo');
        

          // Node.js
          process.env["foo"];
        

          // Go
          os.Getenv("foo");
        

          // Java
          System.getEnv("foo");
        

Etc.

Need glue code

Platform.sh / Symfony 3

// platform_parameters.php
if (getenv('PLATFORM_RELATIONSHIPS')) {
    $relationships = json_decode(base64_decode(getenv('PLATFORM_RELATIONSHIPS')), true);

    foreach ($relationships['database'] as $endpoint) {
        if (!empty($endpoint['query']['is_master'])) {
            $container->setParameter('database_driver', 'pdo_'.$endpoint['scheme']);
            $container->setParameter('database_host', $endpoint['host']);
            $container->setParameter('database_port', $endpoint['port']);
            $container->setParameter('database_name', $endpoint['path']);
            $container->setParameter('database_user', $endpoint['username']);
            $container->setParameter('database_password', $endpoint['password']);
            break;
        }
    }
}
$container->setParameter('kernel.secret', getenv('PLATFORM_PROJECT_ENTROPY'));
        

Platform.sh / Go

package conf
import (
  psh "github.com/platformsh/config-reader-go/v2"
)
var PshConfig = createPshConfigObj()

func createPshConfigObj() *psh.RuntimeConfig {
  config, _ := psh.NewRuntimeConfig()
  return config
}
        

package main

func main() {
  engine := gin.Default()
  // ...
  err := ginInstance.Run(":" + conf.PshConfig.Port())
}
        

Platform.sh / Java Spring

package sh.platform.template;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import sh.platform.config.Config;
import sh.platform.config.MySQL;

import javax.sql.DataSource;

@Configuration
public class DataSourceConfig {
    @Bean(name = "dataSource")
    public DataSource getDataSource() {
        Config config = new Config();
        MySQL database = config.getCredential("database", MySQL::new);
        return database.get();
    }
}
        

Platform.sh / Kotlin

package sh.platform.template.spring.kotlin

import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import sh.platform.config.Config
import sh.platform.config.MySQL
import javax.sql.DataSource

@Configuration
class DataSourceConfig {

    @Bean(name = ["dataSource"])
    fun getDataSource(): DataSource {
        val config = Config()
        val database = config.getCredential("database") { MySQL(it) }
        return database.get()
    }
}
        

Use DotEnv (.env files)

(Many to pick from in every language)

Trusted domains

(App-specific configuration)

Constants? Static config files?

Take-away

Dependency inject your environment

User-configured connections

Installers

1. Ask for DB credentials
2. Ask user for basic site info
3. Write credentials to config file
4. Populate DB
5. Write basic site info to config file/DB
6. Profit!!!

Cloud

Better installers

• Pre-include connection glue
• Installer skips pre-populated values
• Do not download from installer

Avoid lock-in

Always be able to
take your business elsewhere.

Use Free Software

Use replaceable services

Google has killed...

• Reader
• iGoogle
• Google Talk
• Google Health
• Knol
• Google Insights
• Picnik
• Buzz
• Aardvark
• Sidewiki
• Notebook
• Dictionary
• Labs
• Wave
• SearchWiki
• Dodgeball
• Jaiku
• Lively
• Page Creator
• Plus
• Zeitgeist
• Answers
• Google X
• Catalog
• Web Accelerator
• Video Player
• Sets
• SearchMash
• Writely
• Plus+

Source: WordStream (2015)

Microservices: Threat or menace

Properties of microservice design

• Single-purpose components
• Dumb pipes (HTTP, IPC, etc.)
• Separate teams
• Independent releases

(Sources: Wikipedia, Martin Fowler)

Every microservice treats every other microservice as a separate 3rd party
that may as well be a different company.

Benefits

• Different tools/languages
• Small, focused, interdisiplinary teams
• Strong separation of concerns
• Scale/evolve/replace separately

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

—Conway's Law

Drawbacks

• Network latency
• Network points of failure (plural)
• Transitioning code is 10x harder
• API versioning
• More staff needed
• PHP startup time

"If one of your microservices going down means the others don't work, you don't have a microservice; you have a distributed monolith."

—A few dozen people

So if microservices aren't for me, what is?

Multi-Modal Monolith

Multi-Modal Monolith

• Single team
• Discrete components
• Deploys as once
• Usually one language (not required)
• May share datastores

You've probably already done this

Multi-Modal Monolith

Cron jobs

"Admin" application

Queue workers

API app

All asynchronous

To summarize...

Remember what they say when you assume