What is Utter?

Utter is a Domain-specific Microservices Framework written in Ruby for building web APIs

irc: #[email protected]

FAQ: How I can package and release my domain/domain-extension/service?

Either you go to the respective .gemspec file and run bundle exec rake release, or you can use utter package

Utter Logger

$log = Utter.logger $log.level = Logger::INFO

$log.debug "this is debug" $log.info "this is info" $log.warn "this is warn" $log.error "this is error" $log.fatal "this is fatal" $log.unknown "this is unknown"

FAQ: What kind of APIs I can build with Utter?

Utter allows you to build both regular and advanced Rule-based web APIs.

FAQ: Why Utter Services can NOT talk to each other?

Utter services are designed to be part of your versioned API, each service handles its own logging and provides its own monitoring mechanism. if you found yourself needing to stack\interface to each others then the Utter suggestion is to revise your architecutral design, as this is where the problem should be addressed and solved, inorder to keep your implmentation "fuck'n Simple", that is the utter way for doing microservices.

What is a Domain-specific Microservice?

A domain is an area of knowledge such as an industry field or a subject of interest. Building an application often requires the utilization of knowledge from a number of different domains. Designing your "Application" on the premise that any authorized entity can utilize the knowledge of a specific domain via interacting with a domain-specific microservice that can do two things, consume messeges and produce messeges.

Utter as a tool is used to manifest the implementation of an Application Model into a number of isolated domains, each refereed to as an Utter Domain-specific Microservice, or an Utter Service for short.

An Utter Service provides an isolation of a domain via defining its bounded context within a single service. Such isolation supports the inhabitance of autonomous small teams. Such teams are more capable of defining and hence understanding the problems involved within a bounded-context domain, moreover utilizting any domain knowledge that already exist of this domain (see Mushin).

As business-inhereted intricate problems on domain basis it is easier to define domain basis as opposed to the much more difficult to define application-as-a-whole basis.

Each Utter Domain-specific Microservice incorporate its Domain-specific knowledge via extensions.

Utter is a - Simplicity Fuck'n Matters - microservies framework for building fun-sized independently deployable services.

Via using Utter each microservice, you create shall exhibit the following Domain-Driven Design coherences: • Complete functionally Resource representation • Append-only Data management • Each microservice handles one resource (or verb), e.g Clients, Shop Items, Carts, Checkout, etc.

  • minmizes the number of choices of Design Patterns per service.

fully acknowldges the philosphy of ... with the caveats of ...

  • seperate reading data from writing data.

autonomous small teams, advocating complex pieces of logic should have , intricate

A Domain-specific Microservice is a declarative Rule-based web service, in the sense that allows a client to interact with it via a Domain-speific Ubiquitous Language(DDD) that changes the state of the system it represents.

In the same sense that natural langauges evolve while preserving its grammer rules, the Domain-specific Ubiquitious Language have a schema which acts as its grammer, or syntax if you may.

The format of the DUL is JSON, making it easily interchangable among different systems and the microservice components.

Example

[

{facts: [

{productions: [

{production_rules: [

{rules: [ {subject: {name: "3am abdo", type: "souq", predicat: "wants", object: "delivery", type: "cup of tea", quantity: "1" }, {name: "ss", age: "11", predicat: kill, method: car accident, object: "john", age: "33"}, {name: "ss", age: "11", predicat: kill, method: car accident, object: "john", age: "33"}, {name: "ss", age: "11", predicat: kill, method: car accident, object: "john", age: "33"} ]}

Declarative microservice means that events changing the state of the system are domain-specific yet indepentant from the technologies(languages\libraries\frameworks) used to implement the microservice. A level of abstraction for interfacing with the domain and not with the implmention technologies.

Utter define a 'Declarative API' as an API that consists of a number of microservices, that takes a JSON payload of "events" form an API client that declares what the system should do (as opposed to how it should do it) and the backend of the API carries the exact same results regardless of the techinical details (implmentation language (ruby, python, etc.) or frameworks used).

Rules allow us to represent certain kinds of knowledge that are difficult to employ a conventional procedural program. Rule-based programs also separate the knowledge from the rest of the program in such a way that a change in the knowledge base is not propagated throughout the program like a change in a procedural program can be.

Microservice Documentation

TODO Checkout Thor soucecode to see how they implment Desc methods to make it similar to generate documentation. TODO Also checkout grape sourcecode Utter under the hood uses sinatra gem to auto-generate an live interactive documentation from your code comments, in example if you mount your microservice on api.mystartup.com/v1/products the live interactive documenations will be auto-generated on api.mystartup/v1/products/docs each user can read it and send json from the documentation pages to your live api.

URL: http://nameko.readthedocs.io/en/stable/about_microservices.html#single-purpose

UseCases

if your enviroment is a polygot of microservcies with different technologies and languages, Utter is the one you should use if you want to write Ruby code.

Somthing like Uber can use Utter to the mess of their system. Utter will divide their system on domain basis, provide their engineers with Rule-based communication to other services, and a dramatically smaller number of services (using domain design as guideline for isolating services)! https://eng.uber.com/soa/ https://eng.uber.com/building-tincup/

What's Utter Main UseCase?

WRITING EFFECTIVE USE CASES: http://alistair.cockburn.us/get/2465

Problem:

Solution: "The programmer should understand what he is doing, that his growing product remains firmly within his intellectual grip" - Dijkstra

Utter offers you the gift of simplicity via an architectural agility that you get from building simple (one fold,), easy(a very near mental leap) microservices; this dominates all other kinds of agility. Good design is about seperating things apart, in the sense that "less is more".

Utter helps you divide up your software project into fun-sized independently deployable microservices.

Utter lets you build fun-sized independently deployable API endpoints.

Reusability\Usability

each utter scopes down its microservice be domain-specific, making it fun-sized codebase. that each domain framework used-by\created-for the microservice can be extended via plugins and reused declarativly in another microservice of the same domain.

Mapping a single domain into many mircroservices. but one microservice to focus on one aspect of the domain and customize its domain stack via extneded middlewares.

Encapsulating functinality is not a new idea, but what makes utter stands out is that the developed codebase now is not only reusable, but actually Usable from the prespective of other microservice developers, as they access the functionality declarativly, without worrying about the implmentation details.

Utter Middleware extensiable architecture makes every compnenet reusable. and Declarative programming makes every component created via Utter highly usable.

What is the Domain-specific Microservices Architectural Pattern?

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.[1] Architectural patterns are similar to software design pattern but have a broader scope. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk. Some architectural patterns have been implemented within software frameworks.

When developing a software architecture, we have to consider not only functional requirements, but also non-functional requirements, such as performance, robustness, failure tolerance, throughput, adaptability, extendibility, reusability, and so on. Indeed, one of the purposes of software architectures is to be able to quickly tell how a piece of software satisfies its requirements.

What is a Domains-specific Microservice?

A Domain-specific Mircoservice is a web service responsible to utilize the knowledge of a specific domain.

How to define the scope of a domain?

Domain scoping is the process that dentifies the domain of interest, the stakeholders and their goals. Domain scoping is economically viable and promises success.

When to extend a domain vs dividing it up into an n number of finer-grained scoped domains?

Knowledge utilized within an Domain-specific Microservice should only belong to its core domain. If the case arises that supporting domains or other generic domains are identifable, then they should be scoped out into their own domains.

How to extend a domain?

What does Utter consits of under the hood?

Sinatra Mushin SSD DiskCloud

What is mushin?

Building an application often requires the utilization of knowledge from a number of different domains. Domain­specific frameworks are source code artifacts, rather limited to mainstream domains such as web, desktop, and mobile development; and they incorporate knowledge from other domains, via extensions. Mushin argues that a diversity of domain­specific frameworks might positively influence the construction of software applications. Hence Mushin intends to support domain­specific framework developers, via providing a generative approach for building domain­specific frameworks, Hoping that this may aid the convergence towards a diversity of domain­specific frameworks and their corresponding ecosystems.

Utter is a - Simplicity Fuck'n Matters - microservies framework for building fun-sized independently deployable services.

Via using Utter each microservice, you create shall exhibit the following Domain-Driven Design coherences: • Complete functionally Resource representation • Append-only Data management • Each microservice handles one resource (or verb), e.g Clients, Shop Items, Carts, Checkout, etc.

  • minmizes the number of choices of Design Patterns per service.

fully acknowldges the philosphy of ... with the caveats of ...

  • seperate reading data from writing data.

Independant

  • Independent Hires\Outsourcing By dividing up your system into Utter services you can safely hire\outsource outsource development for some functionality without the need for them to ever touch your codebase, Simply all they need is the documentation of the APIs they are to interact with.

  • Independent Deployability is key It enables separation and independent evolution of • code base • technology stacks • scaling • and features, too

  • Independent code base Each service has its own software repository • Codebase is maintainable for developers – it fits into their brain • Tools work fast – building, testing, refactoring code takes seconds • Service startup only takes seconds • No accidental cross-dependencies between code bases

  • Independent technology stacks Each service is implemented on its own technology stacks • The technology stack can be selected to fit the task best • Teams can also experiment with new technologies within a single microservice • No system-wide standardized technology stack also means • No struggle to get your technology introduced to the canon • No piggy-pack dependencies to unnecessary technologies or libraries • It‘s only your own dependency hell you need to struggle with  • Selected technology stacks are often very lightweight • A microservice is often just a single process that is started via command line, and not code and configuration that is deployed to a container.

  • Independent Scaling Each microservice can be scaled independently. Identified bottlenecks can be addressed directly. Data sharding can be applied to microservices as needed (Utter uses DiskCloud). Parts of the system that do not represent bottlenecks can remain simple and un-scaled.

  • Independent evolution of Features: Microservices can be extended without affecting other services, For example, you can deploy a new version of (a part of) the UI without re-deploying the whole systemi, You can also go so far as to replace the service by a complete rewrite. But you have to ensure that the service interface remains stable

ref: http://www.pst.ifi.lmu.de/Lehre/wise-14-15/mse/microservice-architectures.pdf

What is Utter?

  • An utter microservice is an endpoint (a web delivery mechanism) on top of a single domain-based bounded context (mushin domain along with plugins).
  • Each utter application is a dockerized straightforward-to-test isolated "SINGLE" versioned independently-deployable Endpoint(with an n number of routes) along with a domain bounded-context.
  • your API documentation acts as the registery of which each team member knows what services are available on which endpoinnds and versions.
  • you build an endpoint service, you deploy it indepentently, you update the centerilized API docs. and the rest of your team and the world get to start using it.
  • utter gives you fine-tuning for which part of your application needs horizontal scale resources, as your application is really divided up into microserices.
  • utter builds endpoints that logs out with 'Correlation IDs' that helps you to stacktrace errors and visualize how services talk to each other.
  • normally the term “micro” refers to the sizing: a microservice must be manageable by a single development team (5-9 developers), Utter argues that a service is a single endpoint/single domain (usually managed by a pair of software engineers). Utter belives that this enforced constrain makes you scale down your domain and its endpoint interfaces small enough but not too small.
  • Independent deployability implies no shared state and inter-process communication (often via HTTP REST-ish interfaces)
  • Functional system decomposition means vertical slicing (in contrast to horizontal slicing through layers)
  • Microservices are fun-sized services, as in “still fun to develop and deploy”

Why Utter

Utter loves sinatra! thats why it is built on top of it, but make smart descions to faciliate the building of microservices. Utter doesn't GIVE A RAT ASS about SQL-based backends integrations (IF YOUR OLD SQL TROLLS AREN't DEAD ALREADY, FIRE'M ALL).

Alternative Frameworks

Utter sees Grape as poluted framework. Utter sees Rails as an ALMOST-ALWAYS A MUST-Avoid framework. Utter sees the Lotus as NOT focused enough on microservices. Utter sees Padrino as Rails wanna-be that provides TOO MANY options! (not microservices specific) Utter sees Ramaze, NYNY, Nancy, Cuba, Camping, Crepe, Hobbit, Kenji, Brooklyn as absoulte yet a GOTO to steal some good ideas! As simplicity is a Prequesite for Reliability, IT FUCK'N MATTERS!

Utter Project Structure

  • ProjectName::V1::MicroserviceName (utter new project asks you about projectname, version, endpoint name i.e gitlapse::v1::lapses)
    • microservice (a microservice web delivery mechanism (interface) of the application Domain bounded context) - NOTE it is "endpoint" and NOT "endpoints"
    • lib
    • lapses_microservice.rb
    • spec
    • lapses_microservice_spec.rb
    • domain (a mushin domain framework, along with its middlewares - thats the lib and spec of your application) - NOTE it is "domain" and NOT "domains"
    • lib
    • lapse.rb (uses mushin framework stack)
    • middleware_name.rb (middleware plugin)
    • middleware_name.rb (middleware plugin)
    • spec
    • lapses_spec.rb
    • Dockerfile
    • Gemfile
    • Rakefile (for running domain and endpoint tests) (rake is also used for building, and running dockerfile as subtitute for my run.sh)

Utter Examples

Example: ========

utter deploy user@serverip

  1. Uses puma and nginx Dockerfile to create a proxy container and bind it to the host server
  2. this command makes a packages gem with the following structure for each endpoint and uploads it to the server
  • Endpoint_name
  • deploy (sourcecode)
    • DATA (docker-volume)
  • Dockerfile
  • Excecute the Dockerfile on the Server

utter new project_name -h gitlab -g projectname create folder structure for project_name asks or uses gitlab username&pass to create a new group named project_name creates a number of endpoints each with its own gitrepo locally and on the specified git host

utter new -e endpoint_name utter new -m model_name utter new -u utility_name utter test -e endpoint # builds the Dockerfile, runs the container, tests it via its local IP utter deploy -e endpoint # checks a configuration yaml file, cp the Dockerfile of the endpoint into a remote server, builds the Dockerfile, bind it to nginx container to expose it to the world.

On the deployment server:

  • Endpoint
  • endpoint
    • DATA (docker-volume)

What is a Microservice? =======================

  • business capability,
  • automated deployment,
  • intelligence in the endpoints, and
  • decentralized control of languages and data.

Why Microservies? =================== Building software is difficult, if software projects are not keen to avoid complexity, they are destined to fall into its traps.

Microservices Architucural pattern Challenges: ================================================

  • Significant Operations Overhead
  • Substantial DevOps Skills Required
  • Implicit Interfaces
  • Duplication of Effort
  • Distributed System Complexity
  • Asynchronicity is Difficult
  • Testability Challenges

How can Utter help? ====================

  • Utter deploy command deploys for each endpoint (endpoint gem + Dockerfile, DATA docker-volume for SSD), nginx image for mapping ports and services.

External Refs:

What is a Rule-based Microservice (Advanced)

A rule-based microservice is a service that allows you to send a set of production-rules(facts) that describe what you like the status of your application to be. In oppostion a normal microservice would ask you to send primative data which you would normall catch on the backend and mainpulate somehow to make it ready suitable to change the state of your application.

In that sense rule-based microservice allows its clients to interact with it via a "Rule Book". clients read the "Rule Book" and send facts to the microservice, the microservice checks the "Rule book" and updates the status of the application accordingly. And as the microservice is domain-specific so is the Rule Book, meaning the clients can always get an Expert's advice on what the status of the application should be. This makes the Microservice highly usable!

More info is always found on hackspree videos or blogposts at hackspree.com; videos and blogposts are part of active hackspree online workshops to which users can register to fully if they like. Also other contributors who provide consulting services for Utter, Mushin, etc. can edit this wikipage on github to add their corrsponding references as well, by no means this is exclusive to hackspree.

https://www.hackspree.com/microservices-course/whatismicroservices.video https://www.hackspree.com/ChainofResponsibilityDesignPattern