codesword

I am thinking of moving all our stateful services to use petset. Check out this link for more information on petset. Postgres, Kafka, Zookeeper and Redis will be affected by this change. This will be an experiment and shall be conducted in a small kubernetes cluster.

###Postgres I don't think there is any very reliable configuration we can use. Let's take a look at postgres k8s for inspiration.

###Kafka We can leverage all/any of this solution.

• Paul Brown's work
• Kubernetes Kafka

codesword

Troubleshooting/Debugging distributed systems is not easy. It can be really challenging if the systems are not thoroughly monitored. Since the begining of this microservice journey, I have been researching the best way we can build our monitoring infrastructure/instrument our code. This is the the solution I am proposing we adopt going forward.

###Prometheus Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Prometheus works well for recording any purely numeric time series. It fits both machine-centric monitoring as well as monitoring of highly dynamic service-oriented architectures. In a world of microservices, its support for multi-dimensional data collection and querying is a particular strength.

We will be using prometheus for all our monitoring needs except in cases where prometheus cannot handle at the moment(eg hystrix metrics). The major reason for choosing prometheus over other monitoring solutions

codesword

You asked a lot of question here. Let me aswer them one after the other.

• What are they? - microservice as an architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. Check out this link for more info.
• What are the upsides of making use of microservices? - their upside include:
  • Large applications are splitted into smaller manageable services which are easy to understand, modify and re-write.
  • Easy to deploy and test each service since it's small.
  • New developers can easily make sense of a small microservice and start contributing immediately unlike a large monolith with millions of lines of code.
  • A microservice can be scaled based on it's needs which might be higher CPU power, bigger memory etc. The whole monolith will need to be scaled even if the performance bottleneck is coming from one small specific section
• Different small teams can work on different

codesword

// Use Gists to store code you would like to remember later on
console.log(window); // log the "window" object to the console

codesword

docker build -t registry.heroku.com/name-of-heroku-app/web .
docker push registry.heroku.com/name-of-heroku-app/web

codesword

machine:
  services:
    - docker
  environment:
    GOPATH: /home/ubuntu/.go_workspace
    IMPORT_PATH: github.com/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME

general:
  build_dir: ../.go_workspace/src/$IMPORT_PATH

codesword

package main

import (
	"io"
	"net/http"
	"os"
)

func main() {
	server := http.Server{

codesword

FROM alpine:3.4
RUN apk add --update bash
COPY artifact /
CMD ["./artifact"]

codesword

Scenario: should get a single job role
    When I am "authorized"
    And there are 2 roles
    And I make "GET" request to "/api/v1/roles/1"
    Then the response code should be 200
    And the response should match json:
      """
      {
        "id": 1,
        "name": "Apprentice",

codesword

require 'spec_helper'

describe 'Todolist App' do
  include Rack::Test::Methods

  def app
    Todolist::Application.new
  end

  it "returns a list of all my todos" do