Skip to main content

Home/ Arquitectura?/ Group items tagged persistence

Rss Feed Group items tagged

Pablo Lalloni

eligosource/eventsourced · GitHub - 0 views

  •  
    The Eventsourced library adds scalable actor state persistence and at-least-once message delivery guarantees to Akka. With Eventsourced, stateful actors: - Persist received messages by appending them to a log (journal) - Project received messages to derive current state - Usually hold current state in memory (memory image) - Recover current (or past) state by replaying received messages (during normal application start or after crashes) - Never persist current state directly (except optional state snapshots for recovery time optimization)
Pablo Lalloni

longevity - 1 views

  •  
    "Model your domain in the language and style of Domain Driven Design. Implement it using Scala case classes and companion objects. Pass us your subdomain, and we provide the persistence. Persistence concerns, operations and data are abstracted behind an elegant persistence API. We provide you with fully featured repositories for MongoDB and Cassandra. We provide a suite of integration tests to exercise your repositories against a real database, as well as in-memory repositories for other tests."
Pablo Lalloni

Building microservices with Scala, functional domain models and Spring Boot - 0 views

    • Pablo Lalloni
       
      Muy buenos slides que muestran un posible modelo a adoptar para arquitectura de microservicios basados en event-sourcing. Imperdible. 
  •  
    "In this talk you will learn about a modern way of designing applications that's very different from the traditional approach of building monolithic applications that persist mutable domain objects in a relational database.We will talk about the microservice architecture, it's benefits and drawbacks and how Spring Boot can help. You will learn about implementing business logic using functional, immutable domain models written in Scala. We will describe event sourcing and how it's an extremely useful persistence mechanism for persisting functional domain objects in a microservices architecture."
Pablo Lalloni

bandicoot - having fun with structured data - 0 views

  •  
    "Bandicoot is an open source programming system with a new set-based programming language, persistency capabilities, and run-time environment. The language is similar to general purpose programming languages where you write functions/methods and access data through variables. Though, in Bandicoot, you always manipulate data in sets using a small set-based algebra (the relational algebra)." "Here are the main features:   - functions are automatically exposed via HTTP using CSV for data, e.g. /List, /Append  - supports persistency via global variables (with transactions and ACID)  - can run on multiple computers to scale up the read throughput  - built in operators from the relational algebra with a simple syntax, e.g. "+" (union), "-" (minus)  - small binary ~100KB"
Pablo Lalloni

Polipo - a caching web proxy - 1 views

  •  
    "Polipo is a small and fast caching web proxy (a web cache, an HTTP proxy, a proxy server). While Polipo was designed to be used by one person or a small group of people, there is nothing that prevents it from being used by a larger group. Polipo has some features that are, as far as I know, unique among currently available proxies: Polipo will use HTTP/1.1 pipelining if it believes that the remote server supports it, whether the incoming requests are pipelined or come in simultaneously on multiple connections (this is more than the simple usage of persistent connections, which is done by e.g. Squid); Polipo will cache the initial segment of an instance if the download has been interrupted, and, if necessary, complete it later using Range requests; Polipo will upgrade client requests to HTTP/1.1 even if they come in as HTTP/1.0, and up- or downgrade server replies to the client's capabilities (this may involve conversion to or from the HTTP/1.1 chunked encoding); Polipo has complete support for IPv6 (except for scoped (link-local) addresses). Polipo can optionally use a technique known as Poor Man's Multiplexing to reduce latency even further. In short, Polipo uses a plethora of techniques to make web browsing (seem) faster."
Pablo Lalloni

chrislewis/highchair - GitHub - 0 views

  •  
    A simple query library for scala and the Google data store.
Pablo Lalloni

Microservices and PaaS - Part I | ActiveState - 0 views

  • Instead of building software that resembles our existing organizations, we should figure out how we want our software to look, then build the organization around that. Or reorganize it if it's already in place.
    • Pablo Lalloni
       
      Las implicancias de esta idea en nuestra organización...
  • When deploying a new feature, enhancing or fixing an existing capability, or deploying an experimental line of code, the previous code remains available and accessible. New code is deployed alongside the old code, with mechanisms in place to instantly route to one or another version.
  • Importantly, the old code is not replaced, but remains part of the system, and is kept running. If, as is often the case, the widespread introduction of the new feature results in unforeseen consequences, the feature flag can be toggled off, and the old version is instantly used instead.
  • ...13 more annotations...
  • In a microservices architecture, an application is comprised of a number of small, independent composable services that interact by way of an external published protocol, such as REST, or a messaging service.
  • Each service is focused on an individual targeted business capability, and thus its scope is minimized. For functionality out of scope, the microservice calls out to other microservices via the published protocol.
  • Small independent microservices can be built using the technology best suited for their requirements. No longer does every application component need to be built on a common company-mandated language and framework such as Java/Spring or Ruby on Rails.
  • Similarly, there's no reason to standardize on a single persistence layer across an entire application. Some microservices might best be served by Redis, others by Oracle.
  • Each microservice can be updated independently, no longer requiring the entire application to be redeployed.
  • Microservices drastically improve the time required to push out a new update, allowing a much more agile development process.
  • Many organizations consist of specialized silo teams (UI, database, API, etc) where costly handoffs and intercommunication are required to coordinate all the pieces of application construction. These handoffs cause overhead, and the need for them should be eliminated.
  • With small teams, each focused on an individual microservice, Netflix enables developers to push code to production, instead of getting mired in a complex deployment process involving several teams.
  • With microservices, the old IT mindset just doesn't work.
  • A centralized IT department cannot possibly cover the wide array of technologies spanning all microservices.
  • Instead a DevOps structure, where each team is responsible for the management of the corresponding microservice, is essential.
  • Enable developers to concoct systems of their choosing with minimal or no interaction from IT, management, VPs, hardware or other groups. "Self Service" is one of the major capabilities offered by the cloud and there's every reason to take advantage of this.
  • Now, IT can be considered as a cloud API available to the developer on-demand 24x7, instead of a complex, process-mired division hidden behind obscure process.
Pablo Lalloni

Microservices and PaaS - Part II | ActiveState - 0 views

  • All aspects of deployment, monitoring, testing, and recovery must be fully automated.
  • Refactor database schemas, and de-normalize everything, to allow complete separation and partitioning of data.
  • There should be no sharing of underlying tables that span multiple microservices, and no sharing of data. Instead, if several services need access to the same data, it should be shared via a service API (such as a published REST or a message service interface).
    • Pablo Lalloni
       
      Aleluya!
  • ...5 more annotations...
  • Instead each microservice should have its own scm repository so it can truly be updated and enhanced independent of other services.
  • Gone are the days of a single monolithic database instance that's shared across all parts of an application.
  • Each microservice must have its own manifest and dependencies, instead of maintaining a global dependency list for all services.
  • Containerization brings countless advantages, particularly a consistent, isolated runtime environment that can easily migrate around the datacenter or around the globe. With Docker and other modern containerization approaches, there is very little overhead in running in a container, and considerable upside.
  • Do not build stateful services. Instead, maintain state in a dedicated persistence service, or elsewhere.
1 - 8 of 8
Showing 20 items per page