All Posts in XPeppers

settembre 21, 2017 - 1 comment.

Come ottenere la certificazione AWS

Gartner 2016 MQ hi-res graphic

Sul fatto che Amazon Web Services sia leader di mercato nel campo dei servizi di Cloud Computing non ci sono dubbi. Per questo motivo la certificazione AWS sta attirando sempre maggiore interesse da parte delle Aziende e dei professionisti IT. Le certificazioni AWS sono l'unico strumento in grado di certificare le competenze e le conoscenze tecniche necessarie per la progettazione e la distribuzione di servizi basati sull'infrastruttura di AWS.

Ottenere la certificazione consente di accrescere la propria visibilità e credibilità, sia quella del Solution Architect che quella dell'intera organizzazione.

XPeppers è Training Partner AWS per l'Italia e una delle domande che spesso ci viene posta è: come ottenere la certificazione AWS ? per questo motivo cerchiamo di descrivere, in questo post, il percorso di certificazione offerto da AWS, illustrando i benefici di ogni singola certificazione, nonché le varie risorse a disposizione del professionista che intende certificarsi.

certificazioni AWS 3

 

Le certificazioni disponibili si suddividono in tre categorie, quella dei Solutions Architect, quella dei Developer e quella dei SysOps Administrator. Ogni categoria ha poi due livelli di certificazione, un livello Associate e un livello Professional.

  • Solutions Architect: le certificazioni di questa categoria sono indicate per coloro che intendano dimostrare le loro capacità nel disegnare architetture IT complesse utilizzando i servizi di AWS. Con questa certificazioni il professionista può certificare la propria capacità a disegnare direttamente su AWS architetture scalabili, sicure e affidabili, così come la capacità di migrare applicazioni multi tier da una soluzione on-premisis ad una on-cloud.
  • Developer: le certificazioni della categoria developer sono pensate per gli sviluppatori che intendano provare la loro capacità a interagire con le API di AWS utilizzando i diversi SDK messi a disposizione. In questa certificazioni si affrontano anche temi come "Code-level application security" (ruoli e utenze IAM, crittografia, etc.)
  • SysOps Administrator: questa categoria di certificazioni è particolarmente indicata per quei professionisti che intendano validare le loro competenze nel deploy, management e operation di servizi su cloud AW.

Il livello associate è il livello base delle certificazioni AWS, mentre il livello Professional è il livello più alto, almeno per il momento. Il questionario, a scelta multipla, relativo alle certificazioni di livello Associate è composto da 80 domande da svolgere in 90 minuti (qui un esempio), mentre il questionario del livello Professional, sempre a scelta multipla, è composto da 150 domande da completare in 180 minuti (qui un esempio). In tutti i casi il questionario è rigorosamente in lingua inglese o giapponese. A mio avviso la difficoltà più grossa, sia per il caso Associate che Professional, consiste nel fatto che oltre ad una buona dose di studio è necessaria una buona carica di esperienza e di Use Case affrontati. Infatti molte delle domande hanno come obiettivo quello di testare la capacità del professionista di utilizzare al meglio i servizi di AWS per risolvere un problema, facendo attenzione al fatto di saper disaccoppiare il più possibile le componenti in modo da aumentare la scalabilità e l'affidabilità della piattaforma. Come prerequisito inutile dire che una buona conoscenza di Networking e SOA aiuta nell'affrontare le varie domande.

Amazon mette a disposizione, sul proprio sito web, vari Labs, Quiz e Videocorsi che aiutano a prepararsi per la certificazione, ma il modo migliore per raggiungere la preparazione necessaria a sostenere un esame è quello di rivolgersi a uno dei tanti Trainer Partner presenti in tutto il mondo. I nostri corsi sono strutturati per permettere di affrontare tranquillamente una sessione di esame e i nostri docenti sono altamente qualificati avendo seguito un percorso di formazione direttamente presso i Training Center di Amazon Web Services. A seguire una tabella che per ogni certificazione suggerisce il relativo corso di formazione.

AWS Certification Exam Recommended AWS Training
AWS Certified Solutions Architect - Associate Architecting on AWS
AWS Certified Solutions Architect - Professional Advanced Architecting on AWS
AWS Certified Developer – Associate Developing on AWS
AWS Certified SysOps Administrator - Associate System Operations on AWS
AWS Certified DevOps Engineer - Professional DevOps Engineering on AWS

Veniamo ai costi. Il costo delle certificazioni varia da 150 Euro per la certificazione Associate a 300 Euro per la certificazione di livello Professional per tutte e tre le categorie. Inoltre partecipando ai corsi offerti dai Training Partner è spesso possibile ottener degli sconti. Gli esami di certificazione sono gestiti attraverso i Testing Center accreditati PSI, puoi prenotare una sessione direttamente dal portale training AWS.

Per qualsiasi informazione relativa ai corsi su Amazon Web Services non esitare a contattarci o visita l'elenco dei corsi e date disponibili: http://www.xpeppers.com/corsi-di-formazione-aws/

 

 

settembre 15, 2017 - No Comments!

WeDoTDD: That’s How

We recently did an interview on wedotdd.com on how we practice TDD. We decided to share our answers also in our blog, keep on reading if you want to know more!

 

Pairing in Peppers

 

History, what you do now, anything that summarises you or makes you interesting

An agile software developer at XPeppers has on average four years worth of experience in agile methodologies and has therefore grown a skillset that ranges from Clean Code and Refactoring to Test-Driven Development. Our software developers spend most of their work hours crafting customer ideas into great software.

All team members at XPeppers focus on their continuous improvement by investing time in studying new technologies and paradigms, doing katas and setting up coding dojos and presentations.

How did you learn TDD?

Each developer who joins our team has a study path to follow and has a mentor that helps them learn all the things we value most at XPeppers, among which you can obviously find TDD.

We know that TDD can be learnt only with practice and therefore we suggest katas and organise internal coding dojo during our study time to both improve our skills and share ideas. We try to teach our developers TDD "on the field" by pairing up developers who are less experienced on TDD with our XP coaches.

Our developers quickly get that TDD has a huge impact on the quality of the code they craft and easily become engaged with it. With time they understand that tests are not only a good way to avoid regressions but also a great tool to improve code design.

Tell us more about how your team pairs

At XPeppers we try to work on uniformed pairing stations that run similar software. In addition to this, we’ve noticed that large desks with big monitors encourage a more natural role and keyboard switch.

During our pair sessions we do talk a lot (hence we’re italian :P) and collaborate in order to make better design decisions and write better code in general.

Another practice we sometimes do is to pair (on site and remote) with a member of customer's team to enhance domain knowledge and share development best practices.

More Details About the Team Itself

At XPeppers every team is shaped according to customer needs and follows a project from the beginning until its delivery. Its members however, might be adjusted based on iterations and workload whereas the team ideally is cross-functional by nature. In this way we are able to enhance our focus on a specific product and share experiences throughout the team on a project based manner.

Every month we update our projects portfolio board to both assure everyone is allocated and to have a more long term view of ongoing projects.

What role does QA play on the team? How do they interact and work with the developers, Project Managers, etc.?

In some of our projects we have a QA person that tests the user stories when they are available on a production-like environment. Usually they try to replicate the requirements written in the back of the user story.

In some other projects we write an automated user acceptance test and we have a set of UAT that proves that our software works as intended (or expected) by the customer.

What kinds of products does the team support / develop?

We have huge experience on financial applications: we built both Mobile Payment Apps for iOS and Android and backend payment gateways for some of the biggest players in Italy.

We are confident with API development (lately we are working extensively with Serverless Architectures).

The XPeppers team has many other successful case studies with different customers among with you can find famous newspapers, networking companies and public institutions.

Can you describe in detail the team methodologies & workflow when developing software

Every XPeppers team has its Product Owner which talks directly with the customer to collect the requirements and other information such as some priorities including scope, time and quality. In this way the PO can better understand the real customer needs.

Then the team takes part to a KickOff meeting in order to update all the team members on projects goals, the expected results, the timing and the process.

The whole team defines the priority for each story to minimize the time spent to have a working software that can be tried and approved by the customer.

A story complexity is estimated in points based on the team experience or on a spike made before. The points are assigned following the Fibonacci scale starting from the simplest story.

We use a physical Kanban-board every time is possible. If a team is distributed we have a virtual board, even if we often reply it in a physical format for visualisation convenience.

We schedule meetings with the customer every 1 or 2 weeks to do a demo of the software and plan which stories to include in the following iteration.

In XPeppers we adopt many XP practices like Pair Programming, TDD, Code Review. We rely on the type of customer/project to choose the practices that help us to enhance the quality of the project, the development process and the relation with the customer.

Can you describe a typical / common setup of a developer machine?

A typical developer machine at XPeppers is a MacBook Pro 13' or a Dell XPS 13'. We have an IDE to work with languages like Java or C# and an editor like vim, emacs or atom.

We follow the Agile Manifesto, so we value people more than tools: this is why we try to decide as a team which configuration is best suited for a given project.

Can you explain in detail the different types of tests the team writes and in what contexts or at which levels (boundaries) of code?

We use to write different kind of tests based on the project context. Basically, using TDD, we happen to leave a trail of tests behind us, which are going to be the core of our test suite. We tend to cover the code strategically: the most important or risky is the feature, the more tests we write for that part of code. We also write integration tests, to verify the behaviour of the system (or one of its part) as a whole. Those tests are all written by developers as part of their day-to-day work. We then also write Acceptance Tests, which we use to discuss and clarify features with customers. Those are the main type of tests we write.

Just to give a concrete example, those are some numbers taken for two big-sized projects:

  • 2,500 Unit tests, running in about 30-40 seconds
  • 200 Integration tests, running in about 19-20 minutes
  • 250 Acceptance tests, written as Cucumber scenario tests, running in about 12-18 minutes against a production-like deployed application
  • 2,308 Unit tests, running in about 10-15 seconds
  • 556 Integration tests, running in about 6 minutes
  • 502 Acceptance tests, running in about 17 minutes against a production-like deployed application

Depending on the project context, we may decide to write also other type of tests, mainly smoke tests and stress tests.

What is the team's style / approach to TDD?

As a consulting company, we don't have a team style or specific approach to TDD. We'd like to see TDD as an effective practice to build working software. We try to choose the approach that best fit particular situation, team or product.

When we are working with an external team, like customers who are approaching TDD for the first time, we like to keep a smooth and very strict rhythm so that people can appreciate, learn and better understand the practice. From the other hand, we tend to shift to a faster and less strict approach when we are working with more experienced people or when the confidence about the domain is high we tend to go faster.

Explain how you refactor your tests (blue step in TDD)

We try to make a refactor step after each test pass and try to enhance code in order to embrace business changes needs or reduce technical debt.

When our application is hard to change, we know we should refactor our code.

If we cannot do it immediately (e.g. due to a short deadline) we create a card with TD (Technical Debt) label and we do it as soon as possible.

Are there any refactoring patterns or techniques that you apply to the production code?

There are different patterns that we employ everyday in order to improve the design of our production code, avoid duplication and express in a better way the intent of each component. Each person in our team has a different set of patterns in their toolbox but we try to use those that answer the four rules of simple design; anyhow most of the patterns we employ are taken from two books we warmly recommend: Refactoring by Martin Fowler and Refactoring to Patterns by Joshua Kerievsky.

How has TDD helped the team design better code?

TDD helps our teams in many ways. It allows us to see a new feature from the customer point of view.

In addition we can write more meaningful code for the business needs, which leads to have the code cleaner and more understandable for the entire team.

It permits to have a quick feedback and to not over-engineer the application, because we write only the code that is really needed.

How has TDD benefited your customers and client's projects?

Our customers feel a better quality in the software we deliver, because there are few bugs and we can fix them quickly.

The customer asks for new features with more confidence and trusts us. The software turns out to be more flexible and easier to extend.

What are some challenges the team has faced with TDD?

There are many challenges that we try to face when we practice TDD in our team, and these challenges are not only related to technical aspects but also to different approaches that come from our different experiences.

In some situations we discuss a lot about the first test we should write when developing a new feature: shall we start with this case or another? In other cases we have to think carefully on our TDD approach; of course we love outside-in TDD but sometimes when we are confident we embrace inside-out as well.

Another challenge for an experienced member of the team is to pass down some values to younger people: first of all we teach that tests are code and therefore is important to give them all the respect they deserve and polish them using refactoring techniques, DSL etc etc. Moreover tests are made to be read by other people (not always technician) and we must try to make them as much expressive as we can.

Please provide more details on your CI environment or CI environments of the clients you support

The continuous integration environment heavily reflects the project itself. Its complexity and automation degree tell us what kind of environment to spin-up in order to be more effective and productive on a daily basis. We’ve used different tools in the past including Jenkins, GitlabCI, Travis, CodeShip, CircleCI, DroneCI for backend and frontend development. Bitrise and Buddybuild for mobile applications. At XPeppers, we prefer a streamlined continuous deployment or delivery approach to push artefacts towards production.

Please provide more details on your apprenticeship program, internships or on-boarding process

At XPeppers we provide either apprenticeship and internships programs. Both have a strong focus on learning the core principles, values and practices of our way of working.  Apprentices are given the chance to deepen their understanding of eXtreme Programming, Clean Code and TDD by following an ad hoc tailored version of our study path with the support from the entire team.

On-boarding is another very important aspect that helps newcomers to become first-class XPeppers citizens. The on-boarding process is made up of activities other than simply studying, ranging from learning our culture, presenting their progress to others and joining all daily team activities.

How does the team continually learn and improve their TDD and general code design skills?

Each team member at XPeppers has an ad hoc study path to improve both soft and technical skills continuously. We spend a certain amount of time each day to follow this path and to share know how with other team members by making presentations, pair programming sessions and other team activities that help us grow.

Do you talk about TDD with candidates during interviews?

During our interviews at XPeppers we usually ask the candidate whether or not he/she has familiarity with practices such as TDD. If so, we ask further technical information about the subject and adopt TDD during subsequent exercises and pair programming sessions. If it turns out that the candidate has never done nor seen test driven development before, we try to understand how willing the candidate is to learn and improve his/her knowledge of our practices.

settembre 7, 2017 - No Comments!

How to integrate AWS CodeCommit with BuddyBuild: a solution for our Continuous Delivery

AWS CodeCommit - BuddyBuild integrationUsing a Continuous Delivery solution in a software development project is really useful because it brings a great saving of time and costs while providing fast feedbacks on the build.

In our opinion, a Mobile project needs a Continuous Delivery because it enables automation of all time-consuming operations such as tests, builds and releases.

These advantages are even more obvious if applied to a team similar to ours, that follows an iterative-incremental approach to the development cycle with frequent releases.

While developing a mobile app for a customer working on payment services we found ourselves using BuddyBuild as Continuous Delivery service and AWS CodeCommit as Git repository.

Currently BuddyBuild offers a full integration with GitHub, BitBucket and GitLab. It is also possible to use other Git services through SSH protocol, but this approach does not support the trigger of an automatic build after a Git push.

Therefore we had to find an alternative solution in order to have a complete and automated Continuous Delivery cycle.

First Approach

Initially we had to configure a local script shared throughout team members to automatically trigger the build at every push towards CodeCommit. In this way we use a "git post-push" hook to call the BuddyBuild API.

This approach gave us some trouble over time.

In particular we faced problems with new team members which had to configure the script on their own machine. Furthermore every change to the script had to be propagated on every already configured environment.

New Approach with AWS Lambda

AWS LambdaRecently, AWS introduced the opportunity to trigger an AWS Lambda from a CodeCommit event such as a push, branch creation, etc.

Therefore we decided to develop a small project to integrate CodeCommit and BuddyBuild. We created a Lambda which is triggered by CodeCommit at every push and uses the BuddyBuild API to run a new build.

DockerWe create a new project using Docker as Development Environment. This permits to have an environment as similar as possible to the container inside which AWS Lambda runs the code. Other reasons we like working with Docker are that we can replicate through different team members the same Environment and we can keep our host machines clean.

We use Serverless Framework to develop and deploy the Lambda project but at time of writing there is no support to the CodeCommit event, so we have to manually configure the trigger from the AWS Console.

The function itself is very simple. It's an HTTP request to BuddyBuild API that needs only APP_ID and USER_TOKEN to be configured.

Here a piece of the Lambda source code:

request({
 headers: {'Authorization': `Bearer ${process.env.ACCESS_TOKEN}`},
 uri: `https://api.buddybuild.com/v1/apps/${process.env.APP_ID}/build`,
 method: 'POST'
} /*, [...] */ )

For security reason we get BuddyBuild tokens and AWS credentials from environment variables, in this way everyone can configure these variables with an .env file without pushing them to the repository.

We chose to open source the code which is now publicly available on GitHub: CodeCommit - BuddyBuild Integration: all feedbacks are welcome 🙂

agosto 22, 2017 - No Comments!

Cosa ascoltiamo in XPeppers

I podcast sono un ottimo modo per restare aggiornati sulle tecnologie e metodologie che utilizziamo quotidianamente e per questo ne ascoltiamo in abbondanza. Nelle nostre playlist ci sono episodi di svariati podcast:

Software Engineer Radio - una risorsa di apprendimento per tutti i software developer. Gli argomenti trattati sono molto variegati e trattano molti aspetti del nostro lavoro. Dal punto di vista della qualità delle interviste è senza dubbio il numero uno.

Scrum Master Toolbox Podcast - il miglior podcast sui metodi agili, ottimo soprattutto se vuoi migliorare come scrum master ed agile coach. I nostri Pietro di Bello e Paolo D'incau sono stati ospiti dell'host Vasco Duarte.

Altri podcast sul tema agile che ci sentiamo di consigliare: Agile CoffeeThe Happy Melly PodcastLean Change ManagementAgile in 3 MinutesThe McCarthy ShowThe Agile RevolutionITkanban's podcast
Sul tema DevOps invece The Ship Show e CenturyLink Labs Podcast sono i nostri preferiti.

The Ruby Rogues - a panel discussion about topics relating to programming, careers, community, and Ruby. They release a conversation with notable programmers and Rubyists each week to help programmers advance in their careers and skills.

JavaScript Jabber - si parla di sviluppo sia client che server side, di pratiche di programmazione ed environment legati a questo linguaggio. Sono frequenti le interviste con i maintainer delle più famose librerie e framework per avere un aggiornamento direttamente alla fonte.

Tra gli altri, nei nostri Overcast potete trovare:

  • vJug - audio recordings from virtualjug.com
  • The Changelog - a weekly conversation that gets to the heart of open source technologies and the people who create them.
  • Being The Worst - audio apprenticeships for the aspiring software craftsman. Currently exploring DDD, Event Sourcing, CQRS, distributed systems, cross-platform, cross-cloud, & cross-language software delivery.
  • Under the Radar - from development and design to marketing and support, Under the Radar is all about independent app development.
  • SharedInstance - a podcast about iOS Development from three iOS Developers based in Cincinnati
  • Software Process and Measurement Cast - Interviews, essays, facts and tips about process improvement and measurement in the Information Technology arena
  • AWS Podcast - Simon Elisha & Jeff Barr discuss various aspects of the Amazon Web Services (AWS) offering. Each podcast include AWS news, tech tips, and interviews with startups, AWS partners, and AWS employees.
  • 21st Century Work Life - remote working, virtual teams and flexible working.
  • High Resolution - video podcast series with 25 masters of the design industry
  • Freakonomics Radio - each week, hear surprising conversations that explore the riddles of everyday life and the weird wrinkles of human nature—from cheating and crime to parenting and sports.

 

 

giugno 29, 2017 - No Comments!

Preparati a diventare un AWS Specialist in Big Data

AWS Certified big Data

L’esame di certificazione Big Data in AWS è stato da poco rilasciato. L’ottenimento di questa certificazione ti permette di imparare nuove skills e portarti ad un avanzamento di carriera come professionista nel campo dei Big Data e Analytics.

Diventerai tra i primi al mondo in possesso di un titolo di specializzazione sui Big Data con AWS

L’esame è rivolto a persone che operano analisi complesse di Big Data e valida l’abilità di:
- implementare i servizi core di AWS Big Data con le best practices architetturali;
- sfruttare e automatizzare strumenti di data analysis.

Il formato dell’esame è quello solito, si può prenotare una sessione direttamente dal portale di training AWS e sostenere l’esame con domande a risposta multipla in un tempo massimo di 3 ore. Il costo di registrazione all’esame di certificazione è di $ 300.

Nel percorso di studio consigliato da Amazon c’è il corso Big Data on AWS che offriamo regolarmente on-site e in classi pubbliche a partire da € 750. Ulteriori materiali utili per prepararsi sono i whitepapers  e la documentazione.

Prima dell’esame ti consigliamo di visualizzare il blueprint dell’esame disponibile qui. In questo documento sono elencati i prerequisiti e la lista degli argomenti su cui prepararsi.

Il nostro trainer Claudio Pontili a proposito della certificazione: "la certificazione Big data è difficile al pari delle altre advanced. Per il superamento dell'esame il corso è fondamentale, e sono necessari almeno 6 mesi di utilizzo di AWS per conoscere al meglio gli aspetti più particolari dei servizi di big data come Amazon Elasticsearch Service e Kinesis.

La certificazione ti da un valore aggiunto, ormai ci sono tantissime persone che si spacciano per "big data specialist" ma pochi di questi sono veramente competenti in materia, con questa certificazione puoi effettivamente dire di saperci mettere le mani."

I nostri trainer hanno già sostenuto l’esame di certificazione Big Data e sono a disposizione per suggerimenti e indicazioni per raggiungere l’obiettivo.

aprile 26, 2017 - No Comments!

Container Conference in Chiasso

Due giornate dedicate ai temi del DevOps, la Containerizzazione delle applicazioni e lo sviluppo di architetture a Microservizi

L’ agenda per l’evento dei Containers a Chiasso (23-24 maggio) è stata appena annunciata e vi consigliamo di prendere subito i biglietti scontati.
Per iniziare avremo con noi Mattia Gandolfi di Google, che ci parlerà di Kubernetes il tool di riferimento per il deploy, scaling e gestione di applicazioni containerizzate.
Direttamente da Mesosphere DC/OS, Jörg Shad ci parlerà di come mantenere l’applicazione resiliente, nonostante errori di rete, aggiornamenti o bug.

Vedi l’agenda completa

Il giorno 23 Maggio è interamente dedicato ai workshop, tre opzioni super interessanti per capire come realizzare applicazioni sul cloud, containerizzarle con Docker o farle evolvere verso un’architettura a microservizi. CTO, developers e operations non possono perdersi questa opportunità di formazione. Scriveteci per sconti e biglietti di gruppo.

Prendi i biglietti

 

marzo 15, 2017 - No Comments!

Incontro DevOps Italia – Si fa presto a dire Serverless

Ultimamente si sente molto parlare di architetture Serverless, un termine per certi versi ambiguo e legato a troppi diversi significati che secondo noi non esprime ciò che in realtà si vuole comunicare.

 

All'Incontro DevOps Italia Alessio Coser e Daniel Depaoli hanno tenuto una presentazione su questo tema iniziando con una breve introduzione a questa architettura chiamata anche Function as a Service (FaaS).

Applicando l'architettura FaaS in vari progetti abbiamo raccolto delle riflessioni su quali siano i vantaggi e le sfide che si devono affrontare nell'utilizzo di questa tecnologia.

Le slides della presentazione

 

Da queste esperienze abbiamo creato dei corsi per capire come implementare correttamente una architettura Serverless in modo da gestire le complessità e rendere i cambiamenti futuri più facili: vedi il programma.

marzo 6, 2017 - No Comments!

“How Agile Dev Teams work” – Our seminar @ICTDays 2017

seminar picture

Last Thursday, in a joint effort with Paros s.r.l., we held a seminar at the department of Information Engineering and Computer Science at the University of Trento.

It was the final event of the day for the 2nd of March and a part of the ICTDays program, which is a set of activities spanning across a couple of weeks, organized to facilitate the meeting between Tech companies and Information Technology students that are looking for career opportunities.

We have worked with the Paros team for a cumulative period of almost three years now, and we were looking to share our experience and introduce the attending students to what an Agile transformation may look like - maybe in a company they could be working for in a few years (or months) from now.
(You will be able to read more about our successful collaboration with Paros in an upcoming and more comprehensive case study, so be sure to keep up to date with our latest news!)

The Seminar:

After a brief intro about the Agile principles and manifesto, we talked about the "old way" of doing things.
No shared knowledge about the product, long requirement gathering cycles, impossibly complicated deployment procedures, very few opportunities for growth... You name it.
We then proceeded to illustrate how XPeppers and Paros started their collaboration. One step at a time, it managed to change the company culture, leveraging on the work of both teams.
This introduced a long series of benefits, starting from a collective code ownership of the development team to a deeper commitment to the product across all departments - simply a more efficient process all around.
In particular, we focused on the introduction of Scrum, which allowed us to focus on creating business value: rather than planning in terms of technical considerations, such as software layers, this framework helped the team to plan in terms of benefits for the customers and their final users.
The following step was introducing technical practices taken from Extreme Programming, like TDD, Continuous Integration, Refactoring, which allowed the team to develop the kind of technical excellence needed to be able to release early, often and continuously.

You can look at our slides here!

https://docs.google.com/presentation/d/1pyRu8DJr05iFzIazOUs4HJuZ7_osMs_p-Ua_8VsFoKw/edit?usp=sharing

What we have learned:

At the end of the talk, we had the chance to answer interesting questions from the students spanning across a wide range of subjects: from the technical, down to earth stuff to the most abstract concepts addressed by our process.

It was a very stimulating experience and a chance to take a fresh look at our company environment from the perspective of young, newly trained people.
We are definitely looking forward to more opportunities like this one, where we get to keep in touch with the emerging professionals in our field.

If you were attending our seminar, please let us know your feedback and any questions you may have left by contacting us through our website.
We'd love to hear from you!

febbraio 13, 2017 - No Comments!

Case Study PhotoVogue

Photovogue

Nata come società di stampa, al giorno d'oggi la maggior parte dei contenuti di Condé Nast è distribuita attraverso canali digitali, per cui sono necessari la stabilità delle piattaforme di distribuzione e la flessibilità della tecnologia.

PhotoVogue, parte del marchio Vogue, è una piattaforma per i fotografi che vogliono mostrare il loro talento con la possibilità di partecipare a mostre internazionali e iniziative e la possibilità di essere rappresentato da un'agenzia di New York Art + Commerce, una delle più prestigiose al mondo.
La piattaforma, lanciata nel 2011, aveva bisogno di un importante aggiornamento della tecnologia per supportare la crescita costante. Nel corso del kickoff del progetto il team ha deciso di sfruttare tutte le tecnologie all'avanguardia fornite da Amazon.

Abbiamo partecipato all’implementazione nel corso di un periodo di tempo di tre mesi, portando l'adozione di metodologie agili e le operazioni automation di infrastruttura. Amazon ha realizzato un case study sul progetto.

La soluzione

serverless architecture

  • AWS Lambda abilita la scalabilità automatica in base al traffico di PhotoVogue to scale.
  • Il Web Client di PhotoVogue utilizza le API REST costruite con AWS Lambda e AWS API Gateway.
  • Gli utenti possono caricare le loro foto utilizzando la funzionalità delle S3 Pre-Signed URLs.
  • AWS S3 scatena una AWS Lambda function che converte la foto caricata dall'utente in vari formati.
  • AWS RDS con MySQL sono usati come servizio di database.
  • AWS CloudFront è usata come content delivery network per i contenuti.
  • AWS API Gateway è usato come layer di caching per le API rest.

Leggi il case study: https://aws.amazon.com/solutions/case-studies/photovogue/

febbraio 2, 2017 - No Comments!

Nuovo Workshop – Build, test and run a microservice, in AWS Elastic Container Services

Un nuovo workshop si aggiunge al nostro catalogo, la prima edizione sarà il 9 marzo a Bologna in occasione di Incontro DevOps.

tweet workshop

Le sfide che portano ad un sistema distribuito basato su micro-servizi sono molte. Le aziende devono spesso modificare il loro modo di sviluppare, il loro modello organizzativo deve adattarsi ai processi DevOps e le scelte tecniche devono essere orientate a disaccoppiare il più possibile i componenti. Amazon Web Services sta rapidamente abbracciando architetture basate su micro-servizi cloud-native. Per velocizzare l’adozione dei micro-servizi AWS ha introdotto Docker come sistema per “containerizzare” i carichi di lavoro di applicazioni esistenti o nuove. In particolare AWS ha lanciato il servizio ECS (Amazon Container Service) per gestire in maniera semplice ed efficiente un cluster di tali container e ECR (Elastic Container Registry) come registro di contenitori Docker completamente gestito.

workshop

Durante il workshop metteremo in piedi una pipeline attraverso il servizio AWS CodePipeline che ci permetterà di automatizzare il flusso che va dalla creazione dell’intera infrastruttura, utilizzando AWS Cloudformation, fino all’esecuzione del servizio sul cluster Amazon ECS.
Vedremo poi come Amazon Blox (progetto open-source) ci fornisce una serie di API per creare orchestratori personalizzati.

Argomenti

- Deployment on AWS (CLoudformation, Opsworks, Beanstalk)
- CI&CD on AWS (CodeDeploy, CodeBuild, CodePipeline)
- Container on AWS (Elastic Container Services)
- All together: build, test and run a microservices

Cosa Impareremo

Impareremo a creare una Pipeline di CI&CD che va dal test di un micro servizio fino al deploy su un cluster di container docker passando per la creazione automatica dell’infrastruttura (Infrastruttura come codice).

A chi è rivolto

DevOps Engineer, Systems Engineer, Developer

Requisiti

Notebook con:
- Docker
- Apache Maven
- Editor (Atom, Sublime, etc)
- AWS Command Line

Docente

Paolo Latella

Prendi il biglietto per il workshop:

Eventbrite - Incontro DevOps Italia 2017
Non riesci a partecipare o vuoi offrire questo workshop al tuo team? contattaci per un'offerta onsite