altsang

for sure, it's like the Golden Gate bridge too - once you're done on one end of painting it's time to start re-painting from the beginning again

LoopBack.io powers the Compose capabilities in LunchBadger. We're built entirely on open source! Super productive for API development - we just fill in the rest of the blanks in the lifecycle

it gets better over time :)

Not exactly in the traditional sense, a Dapps is a decentralized app that runs on Ethereum, to bridge the gap beyond blockchain execution, the embodiment of a Dapp across all of its smart contracts to a traditional application is ideally - a microservice (and API) :)

thx! been a fantastic and learning experience, we've found a sweet spot for blockchain backed APIs and orchestrated microservices with our offering and it's been very exciting!!!

There are no hard rules about how to divide up your microservices and how atomic each one can be. This is an example at the lowest level as projected by Nginx.

We recommend deploying microservices that are encapsulated by domain because 1. locality of operations, 2. dependencies are going to require you rev as a unit. For us, that model could be running in it's own container or with several other related models.

We're talking to many new gen cloud companies that are already in production and have a burgeoning business that they have to support. They're all "sensitive" to cloud lock in and portability is definitely of concerns. What's also interesting is that many have moved from cloud to cloud like AWS to Azure. And many have a combination of clouds as well - a lot more than an I had anticipated!

Everyone who's been in the trenches know that scorched earth big bang replatforming rarely succeeds and never gets completed. Use scripting to wrap around your existing services, carve out microservices with clean interfaces, intense domain focus and go distributed the way you had hoped. We help you do this 0-60 flat in visual canvas, full source code transparency, saving you tons of time repeatedly.

We've standardized on docker containers, so any scheduler should be able to run your APIs and microservices. For now we've used Kubernetes for deployment and managing those containers. If you have your own scheduler it would be possible to swap it out with an on-premise deployment. What Kubernetes lacks in terms of dedicated professional support it makes up with the most active and helpful community.

Thanks! We think what we've built can potentially give you the best of both worlds. No one is going pigeonhole your entire API solution into just serverless infrastructure. But a portion of it can be and should be if you want the most efficient cost of compute and manageability.

Very very true. Cost of compute is already published per cloud provider. For example, on AWS, it's currently first 1M is free. After that it's a million per $.20. At some point of volume depending on your use case there's going to be an inflection of just running your own container or VM. The bigger challenge here is tracking and understanding your usage as it pertains to your application, beyond the compute resources on a per call basis. We're intending on building governance and metering for infrastructure usage as part of our orchestration solution to help shed light on this area.

That's true to a certain degree. Bare metal VMs running containers server give you OS ioslation but at a cost of an abstraction layer that is not necessarily needed if your interest is only at the container level. That's pretty much why CoreOS, RancherOS and other technologies are out there to be as slim of an OS to just run containers and the bare minimum system processes required. Even system processes are run as containers in RancherOS! APM and other system monitoring tools need to be tweaked for a huge multiplier of processes that are now your distributed app versus that one process that might've been your JVM for example. There's a concerted ops and devops effort that's required to hook into your orchestration layer to get that kind of insight. Roman's next post is going to cover the reasons why we chose the OSS orchestrator that we did.

When it comes to APIs and microservices, you're almost inevitably faced with container sprawl - especially with the ability to deploy quickly and deploy often. Having a good orchestration as described in this post gives you the ability to mind those containers across multiple machines - bare metal or VM, doesn't matter.

We run on top of AWS Lambda - if you choose. Lambda is great but there's still a TON of scaffolding and boilerplate to get your APIs up and running including: model mappings, routing, point to point connection to either HTTP based proxies or Lambda functions. We simplify all of that utilizing the Serverless Framework running LoopBackJS models.

If you're not on Lambda or don't want it - the model logic can be run within our optimized container based runtime built on Kubernetes. Everything is transparent either way built on open source. Where you run it is your choice.

if you're on a AWS, we utilize Lambda to get cost efficiency and predictable cost of execution, we also have a container based runtime that can run your APIs along with everything else that's part of the LunchBadger infrastructure to be run wholly on-premise in your private cloud. To the developer - they write a JavaScript/Node function realizing the serverless simplicity in building out their APIs.

Thanks! That's great point - thanks for pointing out that I need to clarify - that's exactly what we've done.

Built on everything on top of open source and package it up as extensible service or run entire on-premise on your cloud. - The container based runtime is built on top of Kubernetes. - The SCM CI/CD integration and config as code is done via git - The serverless models and functions we're looking to use open source Node.js framework I help create - LoopBack.io, back at StrongLoop. - The GUI is entirely extensible via React and webpack.

The best part is - we've abstracted our interfaces so that your underlying services can be wrapped up in JavaScript no matter what language, OSS framework you have etc - bring it and we'll plug on top of it to help with reducing complexity and saving time.

auto-regression, cyclical, and yes - apply your own via machine learned or manually specified

we're about providing a serverless experience to everyone - regardless of what cloud you're using, the trick though is provide a serverless experience to the devs while giving devops full visibility of what's going on in the runtime

we're looking to support AWS Lambda, as well as other IaaS serverless implementations - but also give you "AWS Lambda in a box" for developer experience - but with devops transparency and control

understanding asynchronous coding in JavaScript - e.g. callback hell, flow control, it's the tradeoff to efficient and scalable processing

for this specific use case? Node.js using LoopBack.io. I/O platform with a framework that was specifically designed for this use case, built on top of Express to save you time.

Full disclosure: I work for StrongLoop and am part of the LB team as a product manager among other things. Check us out - http://loopback.io/. Think Express (it's built on top of it) but with all the bells and whistles to help you with model driven development for APIs to power next-gen web, mobile, S2D IoT, etc. Don't take my word for it - check out our growing community - https://groups.google.com/forum/?fromgroups#!forum/loopbackj....

check it out - http://strong-pm.io/compare/

both are great frameworks, Ritchie was one of the originators of Deployd, LB incorporates lessons learned from Deployd. We have the same WebSocket interface for LoopBack through strong-remoting to support real time. We haven't had time full bake it in, but will soon, especially now finishing up sync and needing server to device push.

Exactly - Loopback = "Parse in an open source box" versus a black-box.