On opportunistic software reuse

The availability of open source assets for almost all imaginable domains has led the software industry toopportunistic design-an approach in which people develop new software systems in an ad hoc fashion by reusing and combining components that were not designed to be used together. In this paper we investigate this emerging approach. We demonstrate the approach with an industrial example in whichNode.jsmodules and various subsystems are used in an opportunistic way. Furthermore, to study opportunistic reuse as a phenomenon, we present the results of three contextual interviews and a survey with reuse practitioners to understand to what extent opportunistic reuse offers improvements over traditional systematic reuse approaches.Peer reviewe

An Approach to Implement SPL Composed of Interconnected Applications and to Deploy them to the Cloud

Las líneas de productos de software (SPL) son una técnica de reutilización sistemática que tanto la academia como la industria han estado utilizando en los últimos años. La idea principal es generar diferentes productos de software a través de la reutilización de un conjunto de assets. Distintos autores han propuesto diferentes enfoques y técnicas para la construcción y mantenimiento de estos assets. Sin embargo, la mayoría de estos enfoques están diseñados para respaldar el desarrollo de aplicaciones independientes y no hay soporte para el despliegue de un producto. En un trabajo anterior, desarrollamos programación orientada a fragmentos (FragOP), que es un marco utilizado para diseñar, implementar y reutilizar activos SPL. Y una herramienta llamada VariaMos que admite FragOP. En este trabajo, mejoramos VariaMos y FragOP para admitir la definición de LPS compuesta por aplicaciones interconectadas y automatizar el despliegue de las aplicaciones generadas en la nube. Finalmente, desarrollamos un ejemplo (un ToDo SPL) para mostrar algunos resultados preliminares del nuevo enfoque.Software product lines (SPL) are a systematic reuse technique that both academy and industry have been using in recent years. The main idea is to generate different software products through the reuse of a set of assets. Dif-ferent authors have proposed different approaches and techniques to the construction and maintenance of these assets. However, most of these ap-proaches are designed to support the development of standalone applica-tions, and there is not support for a product deployment. In a previous work, we developed fragment-oriented programming (FragOP), which is a frame-work used to design, implement, and reuse SPL assets. And a tool called VariaMos which supports FragOP. In this work, we enhanced VariaMos and FragOP to support the definition of SPL composed of interconnected appli-cations and automate the deployment of the generated applications to the Cloud. Finally, we developed a running example (a ToDo SPL) to show some preliminary results of the new approach

Cloud provider independence using DevOps methodologies with Infrastructure-as-Code

On choosing cloud computing infrastructure for IT needs there is a risk of becoming dependent and locked-in on a specific cloud provider from which it becomes difficult to switch should an entity decide to move all of the infrastructure resources into a different provider. There’s widespread information available on how to migrate existing infrastructure to the cloud notwithstanding common cloud solutions and providers don't have any clear path or framework for supporting their tenants to migrate off the cloud into another provider or cloud infrastructure with similar service levels should they decide to do so. Under these circumstances it becomes difficult to switch from cloud provider not just because of the technical complexity of recreating the entire infrastructure from scratch and moving related data but also because of the cost it may involve. One possible solution is to evaluate the use of Infrastructure-as-Code languages for defining infrastructure (“Infrastructure-as-Code”) combined with DevOps methodologies and technologies to create a mechanism that helps streamline the migration process between different cloud infrastructure especially if taken into account from the beginning of a project. A well-structured DevOps methodology combined with Infrastructure-as-Code may allow a more integrated control on cloud resources as those can be defined and controlled with specific languages and be submitted to automation processes. Such definitions must take into account what is currently available to support those operations under the chosen cloud infrastructure APIs, always seeking to guarantee the tenant an higher degree of control over its infrastructure and higher level of preparation of the necessary steps for the recreation or migration of such infrastructure should the need arise, somehow integrating cloud resources as part of a development model. The objective of this dissertation is to create a conceptual reference framework that can identify different forms for migration of IT infrastructure while always contemplating a higher provider independence by resorting to such mechanisms, as well as identify possible constraints or obstacles under this approach. Such a framework can be referenced from the beginning of a development project if foreseeable changes in infrastructure or provider are a possibility in the future, taking into account what the API’s provide in order to make such transitions easier.Ao optar-se por infraestruturas de computação em nuvem para soluções de TI existe um risco associado de se ficar dependente de um fornecedor de serviço específico, do qual se torna difícil mudar caso se decida posteriormente movimentar toda essa infraestrutura para um outro fornecedor. Encontra-se disponível extensa documentação sobre como migrar infraestrutura já  existente para modelos de computação em nuvem, de qualquer modo as soluções e os fornecedores de serviço não dispõem de formas ou metodologias claras que suportem os seus clientes em migrações para fora da nuvem, seja para outro fornecedor ou infraestrutura com semelhantes tipos de serviço, caso assim o desejem. Nestas circunstâncias torna-se difícil mudar de fornecedor de serviço não apenas pela complexidade técnica associada à criação de toda a infraestrutura de raiz e movimentação de todos os dados associados a esta mas também devido aos custos que envolve uma operação deste tipo. Uma possível solução é avaliar a utilização de linguagens para definição de infraestrutura como código (“Infrastructure-as-Code”) em conjunção com metodologias e tecnologias “DevOps” de forma a criar um mecanismo que permita flexibilizar um processo de migração entre diferentes infraestruturas de computação em nuvem, especialmente se for contemplado desde o início de um projecto. Uma metodologia “DevOps” devidamente estruturada quando combinada com definição de infraestrutura como código pode permitir um controlo mais integrado de recursos na nuvem uma vez que estes podem ser definidos e controlados através de linguagens específicas e submetidos a processos de automação. Tais definições terão de ter em consideração o que existe disponível para suportar as necessárias operações através das “API’s” das infraestruturas de computação em nuvem, procurando sempre garantir ao utilizador um elevado grau de controlo sobre a sua infraestrutura e um maior nível de preparação dos passos necessários para recriação ou migração da infraestrutura caso essa necessidade surja, integrando de certa forma os recursos de computação em nuvem como parte do modelo de desenvolvimento. Esta dissertação tem como objetivo a criação de um modelo de referência conceptual que identifique formas de migração de infraestruturas de computação procurando ao mesmo tempo uma maior independência do fornecedor de serviço com recurso a tais mecanismos, assim como identificar possíveis constrangimentos ou impedimentos nesta aproximação. Tal modelo poderá ser referenciado desde o início de um projecto de desenvolvimento caso seja necessário contemplar uma possível necessidade futura de alterações ao nível da infraestrutura ou de fornecedor, com base no que as “API’s” disponibilizam, de modo a facilitar essa operação.info:eu-repo/semantics/publishedVersio

A Web Platform Based on a Multi-Tenant SaaS Architecture to Promote the Accountability of the Social Economy Sector

This work is part of a more comprehensive project whose objective is to develop a platform which supports the operationalization of a framework of indicators to evaluate the financial, social and economic impact of the social economy sector, thus promoting its accountability. In addition, the work intends to assist the institutions of this sector in complying with legal requirements, regarding the disclosure of the financial reports in their institutional websites. Given the low number of institutions complying with this legal requirement and the need to restore credibility to this sector after successive financial scandals, by increasing transparency and promoting its performance, this project is relevant and innovative. This paper presents the conceptualization of the digital platform that underpins the project. With this work in progress, the paper focuses on the presentation of the methodology (Design Science) and the functional and conceptual aspects of the platform that will effectively achieve the objectives of the project

SLA-Driven Governance of RESTful Systems

The Software as a Service (SaaS) paradigm has become entrenched in the industry as a deployment model, bringing flexibility to the customers and a recurring revenue to the business. The main architectural paradigm of SaaS systems is the service-oriented one since it provides numerous advantages in terms of elasticity, fault tolerance, and flexible architectural design. Currently, the RESTful paradigm, a layer of abstraction on the server created by defining resources and entities that can be accessed by means of a URI, is the preferred choice for the construction of SaaS, as it promotes the deployment, isolation and integration of microservices through APIs. Nowadays, APIs are regarded as a new form of business product and ever more organizations are publicly opening up access to their APIs as a way to create new business opportunities. In the same way, other organizations also consume a number of third-party APIs as part of their business. We henceforth define the concept of a RESTful System as an information system following the RESTful paradigm to shape the integration model between both its own components as well as other information systems. Furthermore, understanding governance as the way in which a component is directed and controlled, in RESTful Systems, those components will be the RESTful APIs and what we aim to control or regulate is their behavior (i.e., how an API is being consumed or provided). As APIs are increasingly regarded as business products, a crucial activity is to describe the set of plans (i.e., the pricing) that depicts the functionality and performance being offered to clients. API providers usually define certain limitations in each instance of a plan (e.g., quotas and rates); for example, a free plan might be limited to having one hundred monthly requests, and a professional plan to have five hundred monthly requests. However, although API providers use the Service Level Agreement (SLA) concept to delimit the functionality and guarantees to which they commit to their customers, there is no standard model used by API providers for modeling API pricing (including the plans and limitations). Although some providers do model the information regarding the API pricing and API limitations with an ad hoc approach, there is no widely accepted model in the industry. Wherefore answering questions regarding API limitations (e.g., determining whether or not a certain pricing is valid) is still a manual or non-interoperable process coming along with some inconveniences (being tedious, time-consuming, error-prone, etc.). Understating governance as to how a system is directed and controlled, we translate this concept to meet the SLA-driven approach: we consider the SLA (i.e., API pricing) as the element that will drive the directions, policies and rules to deliver and maintain the RESTful System. Adding the SLA to the idea of governance of RESTful systems leads to the main hypothesis of this dissertation: there is no well-established model for describing API pricings)in RESTful systems, which is hindering the automatic SLA-Driven governance. We claim the main goal of this thesis to be: the creation of an expressive, fully-fledged specification of SLAs for RESTful APIs endorsed with an open ecosystem of tools aimed at the SLA-Driven Governance of RESTful systems. The results of this endeavor are twofold: (I) Creation of a sufficiently expressive specification for the description of API pricings and the analysis of their validity. This comprises: (i) conducting an analysis of real-world APIs to evaluate the characteristics of the API pricings and limitations; (ii) identifying the relevance of SLAs in APIs in both academic and industrial scenarios; (iii) proposing a comprehensive model for describing API pricings; (iv) defining analysis operations for common questions regarding the validity in API pricings and limitations; (v) performing an evaluation of the model in real-world APIs. (II) Implementation of an ecosystem of tools to support the SLA-Driven governance of RESTful APIs. This includes: (i) developing a set of API governance tools; (ii) implementing a validity analysis operation; (iii) performing a validation of the tools and operations in realistic scenarios. In this thesis, we present the Governify4APIs ecosystem as the set comprised of (i) a model aimed at describing API pricings that is closely aligned with industry standards in APIs (OpenAPI Specification) and (ii) a set of companion tools for enacting the automatic governance using our specification, ranging from low-level validation tasks to SaaS solutions based on our model. Governify4APIs is, therefore, a fully-fledged specification, aligned with the mainstream standards and intended to enable an SLA-Driven Governance of RESTful Systems.El paradigma del software como servicio (SaaS) se ha afianzado en la industria como modelo de despliegue, aportando flexibilidad a los clientes y unos ingresos constantes a las organizaciones. El principal paradigma arquitectónico de los sistemas SaaS es la arquitectura orientada a servicios, ya que proporciona numerosas ventajas en términos de elasticidad, tolerancia a fallos y diseño flexible. RESTful, una capa de abstracción sobre el servidor creada mediante la definición de recursos y entidades a las que se puede acceder mediante una URI, es la opción preferida para la construcción de SaaS, ya que promueve el despliegue, el aislamiento y la integración de microservicios a través de APIs. Hoy en día, las APIs se consideran una nueva forma de producto empresarial y cada vez más organizaciones abren públicamente el acceso a sus APIs como forma de crear nuevas oportunidades de negocio. Del mismo modo, otras organizaciones también consumen una serie de APIs de terceros como parte de su negocio. A partir de ahora definimos el concepto de Sistema RESTful como un sistema de información que sigue el paradigma RESTful para conformar el modelo de integración tanto entre sus propios componentes como con otros sistemas de información. Además, entendiendo gobierno como la forma en que se dirige y controla un componente, en los sistemas RESTful, esos componentes serán las APIs RESTful y lo que pretendemos controlar o regular es su comportamiento (es decir, cómo se está consumiendo o proporcionando una API). Dado que las APIs están, cada vez más, siendo consideradas como productos comerciales, una actividad crucial es describir el conjunto de planes (es decir, el pricing) que describe la funcionalidad y el rendimiento que se ofrece a los clientes. Los proveedores de API suelen definir ciertas limitaciones en cada instancia de un plan (por ejemplo, quotas y rates); por ejemplo, un plan gratuito podría estar limitado a tener cien peticiones mensuales, y un plan profesional a tener quinientas peticiones mensuales. Sin embargo, aunque los proveedores de APIs utilizan el concepto de Acuerdo de Nivel de Servicio (SLA) para delimitar la funcionalidad y las garantías a las que se comprometen con sus clientes, no existe ningún modelo estándar usado por los proveedores para modelar el pricing de las API (incluyendo los planes y limitaciones). Aunque algunos proveedores modelan la información relativa a los pricings y las limitaciones de las APIs con un enfoque ad hoc, no existe un modelo ampliamente aceptado en el sector. Por lo tanto, responder a las preguntas relativas a las limitaciones de la APIs (por ejemplo, determinar si un determinado pricing es válido o no) sigue siendo un proceso manual o no interoperable, cosa que conlleva algunos inconvenientes (es tedioso, consume tiempo, es propenso a errores, etc.). Entendiendo el gobierno como la forma de dirigir y controlar un sistema, podemos traducir este concepto teniendo en cuenta el SLA, esto es, consideramos este elemento como aquel sobre el que se realiza la dirección, políticas y reglas para entregar y mantener el sistema RESTful. Añadir el concepto SLA a esa idea de gobierno de sistemas RESTful nos lleva a la hipótesis principal de esta tesis: no existe un modelo bien establecido para describir los SLAs (o pricing) en los sistemas RESTful, lo que está dificultando el gobierno automático. Es, por tanto, el objetivo principal de esta tesis la creación de una especificación expresiva y completa de SLAs para APIs RESTful, respaldada por un ecosistema abierto de herramientas orientadas al gobierno de sistemas RESTful dirigido por SLAs. Los resultados principales han sido: (I) Creación de una especificación suficientemente expresiva para la descripción de los pricings de la API y el análisis de su validez. Esto comprende: (i) realizar un análisis de APIs del mundo real para evaluar las características de los pricings y limitaciones de las APIs; (ii) identificar la relevancia de los SLAs en las APIs tanto en escenarios académicos como industriales; (iii) proponer un modelo completo para describir los pricings de las APIs; (iv) definir operaciones de análisis para preguntas comunes sobre la validez en los pricings y limitaciones de las APIs; (v) realizar una evaluación del modelo en APIs del mundo real. (II) Implementación de un ecosistema de herramientas para apoyar la gobernanza SLA-Driven de las APIs RESTful. Esto incluye: (i) desarrollar un conjunto de herramientas de gobierno de APIs; (ii) implementar una operación de análisis de validez; (iii) realizar una validación de las herramientas y operaciones en escenarios realistas. En esta tesis, presentamos el ecosistema Governify4APIs como el conjunto compuesto por (i) un modelo destinado a describir los pricings de las APIs y alineado estrechamente con los estándares de la industria (OpenAPI) y (ii) un conjunto de herramientas complementarias para el gobierno automático utilizando este modelo, que van desde tareas de validación hasta soluciones SaaS. Por lo tanto, Governify4APIs es una especificación acompañada de todo lo necesario, alineada con los estándares industriales y destinada a permitir un gobierno de sistemas RESTful dirigidos por SLAs

A modeling language for multi-tenant data architecture evolution in cloud applications

Multi-tenancy enables efficient resource utilization by sharing application resources across multiple customers (i.e., tenants). Hence, applications built using this pat- tern can be offered at a lower price and reduce maintenance effort as less application instances and supporting cloud resources must be maintained. These properties en- courage cloud application providers to adopt multi-tenancy to their existing applications, yet introducing this pattern requires significant changes in the application structure to address multi-tenancy requirements such as isolation of tenants, extensibility of the application, and scalability of the solution. In cloud applications, the data layer is often the prime candidate for multi-tenancy, and it usually comprises a combination of different cloud storage solutions such as blob storage, relational and non-relational databases. These storage types are conceptually and tangibly divergent, each requiring its own partitioning schemes to meet multi-tenancy requirements. Currently, multi-tenant data architectures are implemented using manual coding methods, at times following guidance and patterns offered by cloud providers. However, such manual implementation approach tends to be time consuming and error prone. Several modeling methods based on Model-Driven Engineer- ing (MDE) and Software Product Line Engineering (SPLE) have been proposed to capture multi-tenancy in cloud applications. These methods mainly generate cloud deployment configurations from an application model, though they do not automate implementation or evolution of applications. This thesis aims to facilitate development of multi-tenant cloud data architectures using model-driven engineering techniques. This is achieved by designing and implementing a novel modeling language, CadaML, that provides concepts and notations to model multi-tenant cloud data architectures in an abstract way. CadaML also provides a set of tools to validate the data architecture and automatically produce corresponding data access layer code. The thesis demonstrates the feasibility of the modeling language in a practical setting and adequacy of multi-tenancy implementation by the generated code on an industrial business process analyzing application. Moreover, the modeling language is empirically compared against manual implementation methods to inspect its effect on developer productivity, development effort, reliability of the application code, and usability of the language. These outcomes provide a strong argument that the CadaML modeling language effectively mitigates the high overhead of manual implementation of multi-tenant cloud data layers, significantly reducing the required development complexity and time

Achieving Continuous Delivery of Immutable Containerized Microservices with Mesos/Marathon

In the recent years, DevOps methodologies have been introduced to extend the traditional agile principles which have brought up on us a paradigm shift in migrating applications towards a cloud-native architecture. Today, microservices, containers, and Continuous Integration/Continuous Delivery have become critical to any organization’s transformation journey towards developing lean artifacts and dealing with the growing demand of pushing new features, iterating rapidly to keep the customers happy. Traditionally, applications have been packaged and delivered in virtual machines. But, with the adoption of microservices architectures, containerized applications are becoming the standard way to deploy services to production. Thanks to container orchestration tools like Marathon, containers can now be deployed and monitored at scale with ease. Microservices and Containers along with Container Orchestration tools disrupt and redefine DevOps, especially the delivery pipeline. This Master’s thesis project focuses on deploying highly scalable microservices packed as immutable containers onto a Mesos cluster using a container orchestrating framework called Marathon. This is achieved by implementing a CI/CD pipeline and bringing in to play some of the greatest and latest practices and tools like Docker, Terraform, Jenkins, Consul, Vault, Prometheus, etc. The thesis is aimed to showcase why we need to design systems around microservices architecture, packaging cloud-native applications into containers, service discovery and many other latest trends within the DevOps realm that contribute to the continuous delivery pipeline. At BetterDoctor Inc., it is observed that this project improved the avg. release cycle, increased team members’ productivity and collaboration, reduced infrastructure costs and deployment failure rates. With the CD pipeline in place along with container orchestration tools it has been observed that the organisation could achieve Hyperscale computing as and when business demands

Система розробки, безперервної інтеграції та налаштування серверного програмного забезпечення

Робота публікується згідно наказу ректора від 29.12.2020 р. №580/од "Про розміщення кваліфікаційних робіт вищої освіти в репозиторії НАУ". Керівник проекту: к.т.н., доцент Проценко Микола МихайловичA server programming advancement loop is getting more and more dynamic with each day. Different advances, dialects for scripting, libraries and building approaches emerge and leave their mark in software planning acknowledgement. Around the same period, these programs need to be built as well. What used to be a standalone, web-based, dy-namic product, which serves millions of users every day and operates on massive quanti-ties of data every second, was a decade ago. Ceaseless integration and distribution processes, potential server product creation implementation.Цикл просування серверного програмування з кожним днем стає дедалі динамічнішим. З’являються різні досягнення, діалекти сценаріїв, бібліотеки та підходи до побудови, які залишають свій слід у визнанні програмного планування. Приблизно в той же період, ці програми також повинні бути побудовані. То, що раніше було самостійним веб-динамічним продуктом, який щодня обслуговує мільйони користувачів і щосекунди оперує величезними кількісними даними, було десять років тому. Невпинні процеси інтеграції та розподілу, реалізація потенційних серверних продуктів