Group items tagged

"Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA). SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services. SCA is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA compositions. SCA aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, messaging systems and Remote Procedure Call (RPC)."

"The OASIS Open Composite Services Architecture (CSA) Member Section advances open standards that simplify SOA application development. Open CSA brings together vendors and users from around the world to collaborate on the further development and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications."

"Microservices based architectures are not new but are suddenly in the spotlight due to their powerful and sophisticated practices enabling streamlined application development and deployment. However, transitioning from a monolithic approach to a microservices-based architecture requires not only technical expertise, but organizational buy-in as well. In a recent ActiveState webinar, John Wetherill and Phil Whelan discussed a number of tips and tricks to help companies transition to and get the most out a microservices-based approach."

"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."

"This is the first part of a series on building an event sourced application. We'll build a simple blogging application (inspired by the Ruby on Rails "Getting Started" tutorial), so the domain should be familiar. This allows us to focus on implementing a memory image based architecture using event sourcing. Another goal is to show that this kind of architecture is not more complex (and arguably, simpler) than those implemented by traditional database centered applications."

"Ford noted the growing relationship between software architecture and DevOps. The interdependence of the two disciplines is evident within Ford's company: "One of the things that we're really adamant about now," he said, "is that someone from DevOps and operations should be a full-time member of a software development team … you cut way down on churn and other sorts of useless engineering activities.""

"MICROSERVICES ARCHITECTURE GUIDE"

"Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should

Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.

"How to design the architecture of an Angular application"

"The microservices architectural style simplifies implementing individual services. However, connecting, monitoring and securing hundreds or even thousands of microservices is not simple.A service mesh provides a transparent and language-independent way to flexibly and easily automate networking, security, and observation functions. In essence, it decouples development and operations for services.The Istio service mesh is split into 1) a data plane built from Envoy proxies that intercepts traffic and controls communication between services, and 2) a control plane that supports services at runtime by providing policy enforcement, telemetry collection, and certificate rotation.The near-term goal is to launch Istio to 1.0, when the key features will all be in beta (including support for Hybrid environments)The long-term vision is to make Istio ambient."

"At SoundCloud, we structure our product as an API with many clients. That is, our main website, mobile client, and mobile apps are all first-order clients of a single main API. Behind that API is a universe of services: SoundCloud operates basically as a Service-Oriented-Architecture. We're also a polyglot organization, which means we use lots of languages."

"The akka-patterns project is a dumping ground for lessons learnt on a variety of Scala / Akka / Spray topics. At the end of 5 months working on real world (commercial) projects, that were originally based on the akka-patterns architecture, Sam Halliday (@fommil) was asked to document the lessons learnt: Milestone: Lessons Learnt Pull Request: Lessons Learnt This short document is a summary of the highlights from the pull request."

Es muy importante que estudiemos este documento y proyecto todos los que estamos trabajando con akka y/o spray.

Asombroso: un paper de 1994 de investigadores de Sun en el cual concluyen que "RPC" está roto de varias maneras y que no se puede arreglar con ninguna implementación. Ummm... ¿de qué año era CORBA? ¿de qué año era EJB?