RSS

Parse Apps on Flynn

While we were sad to see Parse shut down. We applaud the move to open source the technology behind Parse and provide a clear transition path for users.

We’re committed to making Flynn one of the best ways to run Parse apps.

Flexibility is important to us. We want you to be able to write your apps however you want, using any technologies and run them happily on Flynn. Flynn already makes it easy to run apps written in most languages and frameworks by using Heroku buildpacks and Docker container images. Flynn is also 100% open source and we’re committed to developer tools and infrastructure being as portable as possible.

Because Flynn already has a built-in database appliance for MongoDB, deploying Parse apps is a breeze.

Here’s how to deploy the example Parse app on Flynn:

  1. Clone the repo:

    git clone https://github.com/ParsePlatform/parse-server-example
    cd parse-server-example
    
  2. Create a Flynn app:

    flynn create parse-example
    
  3. Add a MongoDB database:

    flynn resource add mongodb
    
  4. Configure the app (make sure you put your Flynn cluster domain in the SERVER_URL):

    flynn env set MASTER_KEY=myMasterKey SERVER_URL=http://parse-example.demo.localflynn.com/parse DATABASE_URI=$(flynn env get DATABASE_URL)
    
  5. Deploy the app:

    git push flynn master
    
  6. That’s it! At this point you can visit /test to make sure everything is working. Deploying your production Parse apps to Flynn is just as easy, the migration guide is a great reference.

If you need help moving your apps to Flynn drop by our IRC channel (#flynn on Freenode) or tag a question on StackOverflow.

We want you to be able to run every kind of app on Flynn. What other kinds of technologies would you like to see Flynn support?

October Stable Release

October’s stable release is out! It includes an Azure Storage blobstore backend, app garbage collection by default, improved reliability for apps while deploying, and many bugfixes and small improvements. The changelog has the details and there are docs on how to update.

§ Community Articles

§ Flynn at Bitmatica

Carl Minden, Lead Backend Engineer at Bitmatica, explains how they found Flynn and decided to use it in production.

§ Phoenix on Flynn

Phoenix is a popular web framework built on Elixir, a functional, dynamic language based on Erlang. Omar Abdelhafith wrote about deploying Phoenix apps on Flynn.

§ Continuous Delivery Towards Flynn

Philip Lehmann-Böhm wrote about some common patterns for doing continuous delivery with Flynn.

§ F# on Flynn

F# is an open source object-oriented functional language developed by Microsoft. Zohaib Rauf wrote about how to deploy F# Suave apps on Flynn.

§ Stay in Touch

§ How You Can Help

How We Do Databases

Flynn is an open source platform for deploying and managing web applications and databases. You can run it yourself or we can manage it for you.

When we created Flynn, our goal was to build a single platform that ran everything you needed to run your apps. One of the most important and most challenging parts of that vision was how to manage databases.

Setting up and managing databases is one of the hardest things to do in ops. Most databases are difficult to install and configure, especially if you’re trying to use best practices like high availability and automatic failover.

Configuring databases by hand is hard, but automating them so they can manage themselves is much trickier. There are a number of Database as a Service providers out there, but most are closed source and lock you into a single infrastructure provider. For databases to work in Flynn they needed to be completely self-managing, quick and easy to set up, and be able to run anywhere.

We believe the most important job of a database is to keep data safe. When an application tells a user it’s received input, the database needs to hold onto it, no matter what. Unfortunately it’s all too easy to run databases in configurations that lose data when things go wrong, and at scale things always go wrong. Hard drives break, networks partition, uninterruptible power fails, and so on.

We built Flynn’s database appliances to survive those kinds of failure and keep users' data safe.

state machine diagram

Here’s how we do it:

  • High Availability: Flynn’s PostgreSQL, MariaDB, and MongoDB appliances are highly available by default. That means there are always multiple copies of the database running and ready to go. So if something happens to one, the others are ready to take over. As long as you are running three or more servers, Flynn runs multiple copies of the database on different machines, just in case.

  • State Machine: We use a state machine based on Joyent’s Manatee so there’s a chain of replicas: a primary, a synchronous replica, and an asynchronous replica. When an application sends a write to a Flynn database appliance, the appliance will only confirm the write after it’s been copied to the primary and synchronous replica. If the primary goes down, the synchronous replica is promoted to the primary, the asynchronous replica is promoted to become the synchronous replica, and a new instance is created to become the asynchronous replica. This “chain” means that there’s never any question about which replica should take over.

  • Automatic Failover: Flynn’s health check and service discovery services monitor each of the instances in the database appliance’s state machine. It automatically promotes and creates new instances in the state machine. Since this failover is automatic, it can switch over nearly instantaneously and responds much faster than a human operator who receives a page and has to investigate what happened.

  • Whole Cluster Backups: Flynn manages your applications and databases on the same cluster. The command that takes a cluster backup includes databases. It takes only two lines of code to backup a running cluster and restore it somewhere else.

  • Cloud Independence: Flynn doesn’t use any cloud-specific features to run or manage databases. So a Flynn cluster using PostgreSQL and MongoDB runs the same on AWS as it does on DigitalOcean or your own hardware in a colo. Your product and data stay portable, so your options stay open.

We have a lot more features and improvements in the works for how Flynn handles databases. There’s already a solid foundation but we want running all your production databases (and applications) in Flynn to be a no-brainer. You can subscribe to the GitHub issue or sign up for our mailing list to watch our progress.

Managed Flynn, Toronto Meetup, and September Release

The September stable release of Flynn is here! It includes a bunch of bugfixes, a new Google Cloud Storage backend for the blobstore, and some other new features. Read the changelog to learn more.

§ Managed Flynn

We now provide fully managed Flynn as a service in addition to our existing commercial support and training products.

We want everyone to have the best experience with Flynn possible, whether that’s running it entirely on their own, with our help via a support contract, or using a Flynn cluster that we manage for them.

We offer commercial support contracts for users who want to be able to reach our team 24/7 if anything goes wrong. We try to become customers' “backup ops team” and go above and beyond expectations by solving their problems whether or not they’re related to Flynn.

Recently we’ve been approached by users who want even more. Many companies, especially small startups and development shops don’t have (or want) an ops team or sysadmin, or have one solo “devops person”. Some of these users are happy running Flynn on their own, but others have asked us to run everything for them.

We’re launching a beta of Managed Flynn today. Here’s how it works: our team configures, installs, runs, and manages a Flynn cluster for your company. Everything runs in your own cloud account so you always have complete control and ownership of your infrastructure (and can take advantage of any cloud credits you might have). Our team is standing by 24/7 to help your developers get the most out of Flynn and help fix anything that goes wrong with Flynn, your apps, or infrastructure provider.

We’re already working with several managed customers and are excited to see how this scales. As Flynn itself becomes more powerful and feature-rich we’ll be able to offer even more capabilities and guarantees to our customers.

If you’re interested in becoming a Flynn managed customer, please contact us.

§ Toronto DevOps Meetup

Jesse from the Flynn team will be doing a talk about Flynn at DevOps Toronto on Tuesday, October 4. RSVP here.

§ Stay in Touch

§ How You Can Help

Upgrading from Dokku to Flynn

One of the most common ways developers find Flynn is when they’re looking for an alternative to Dokku.

Dokku is a widely used open source mini PaaS. It’s a great introduction to what platforms can offer and easy to get up and running on a single server. It’s also tiny and a model of efficiency, originally written in just 100 lines of Bash.

Many developers choose Dokku because it provides many of the benefits of PaaS, but can be run anywhere on a single server.

Unfortunately the feature that makes Dokku so attractive to developers working on personal side projects, its single host nature, makes it unsuitable for larger and production deployments.

Running as a single instance on a single server prohibits high availability. A single host means there’s a single point of failure. If that server goes down, everything breaks. It also means that users need to do a lot of heavy lifting themselves to scale out.

Flynn includes all the benefits of Dokku without its limitations. One of Flynn’s original design goals was to be the next step on the upgrade path for Dokku users. Both Flynn and Dokku were created to give users the benefits of Heroku, but with more control and the ability to run anywhere they wanted.

Like Dokku, Flynn is also easy to use and install, but scalable, far more robust, and suited to production environments. Everything in Flynn is highly available, so there’s no single point of failure. Even Flynn’s internal components run inside the cluster as highly available Flynn apps.

You can run Flynn on a single server or scale it out to many, many more. Flynn has a web dashboard that makes it even easier to use. Flynn also includes built-in database appliances, which you can think of like having a database as a service (DbaaS) inside your Flynn cluster. Other features you’ll need for scaling production apps like overlay networking and service discovery are also built-in.

If you’re already running your apps on Dokku, it’s very easy to migrate to Flynn. Here’s how:

  1. Install Flynn.
  2. Deploy your apps using git push or Docker images.

It’s that simple.

Since both Flynn and Dokku support Twelve-Factor apps and buildpacks, any Dokku app can run on Flynn.

If you want an alternative to Dokku or just the next step after you’ve outgrown it, Flynn is what you’re looking for.

Our team is available on GitHub, in IRC, and over email if you want help moving your apps or have any questions.

 RSS



Mailing List