Cole Busby

Cloud migrations don’t happen by themselves—there’s no shortage of tasks to complete before declaring the project a success. One of the biggest benefits of a cloud move is the opportunity to reduce toil and operating costs, and one of the most important elements is the automation and configuration of your new cloud infrastructure. By automating the provisioning, configuration, and management of your cloud-based infrastructure, your organization can free up time and resources for mission-critical innovation instead of routine maintenance.

Fortunately, there are many cloud infrastructure automation tools available to help speed the process. In addition, a number of related tools may also be helpful. While no single tool is right for every situation, this guide can help you consider the various benefits offered and choose the ones that best serve your cloud infrastructure needs, whether your migration targets public, private, or hybrid cloud architectures.

AWS CloudFormation

Helping to secure its leadership in all things “cloud,” Amazon’s AWS CloudFormation allows you to model resources in YAML or JSON, automate them, and then deploy them in your AWS cloud-based infrastructure.

If you use or plan to use AWS-based cloud offerings, CloudFormation can help ensure configurations are as easy as possible for all your teams.

CloudFormation lets you run a huge list of other AWS tools right out of the box, including Amazon CloudWatch and AWS Elastic Beanstalk. CloudFormation also handles automated management of cross-region accounts, making it easier to expand into new locales as your business scales. CloudFormation Change Sets are a great way to preview impending changes to your infrastructure before they happen.

If you plan on using the AWS cloud, let CloudFormation do as much heavy lifting as you need it to.

Puppet

A longtime leader in the configuration automation market, Puppet helps some of today’s largest software teams model, configure, and systematically enforce desired configurations of their infrastructures. With Puppet Enterprise—the company’s commercial offering—you can manage all aspects of your cloud-based infrastructure, from compute to storage to networking resources, at an impressive scale (think upwards of 20,000 nodes for a basic deployment). And it works on public, private, and hybrid clouds. You write modules in Puppet’s domain-specific language (DSL) that provide code for the configurations that are enforced by an agent you install on each node.

With Puppet Enterprise, you get out-of-the-box orchestration and task-based command execution and multi-device management. It’s GUI console makes it easy to classify and manage all the cloud machines you’ve deployed. And while the Puppet DSL is known for taking a while to learn, the payoff can be huge.

Puppet maintains integrations and partnerships with major players like Microsoft, VMware, Google, and Amazon. AWS Opswork for Puppet Enterprise, for example, provides a fully integrated suite of automation tools for managing your cloud-based infrastructure.

If on-the-mark enforced configuration and drift remediation is what you need, Puppet is the automation tool for you.

Ansible

Recently brought under the RedHat umbrella, Ansible is quickly becoming an industry standard based on its easy-to-use, task-based infrastructure automation. Ansible boasts that you don’t need an advanced degree in computer science to write automation, configuration, or orchestration tasks in its simple language, which you package in “playbooks.” Additionally, you can easily manage all aspects of your cloud infrastructure without installing a single agent anywhere in your cloud infrastructure.

Key capabilities of Ansible Tower (Ansible’s commercial offering) include job scheduling, GUI-based inventory management, multi-playbook workflows, and a flexible REST API that lets you embed Ansible Tower in almost any task-based configuration management process.

Major integrations include AWS, Microsoft Azure Cloud Computing, VMware, Rackspace, Digital Ocean, and Google Cloud Computing.

Automating configurations with Ansible’s tasks execution may make your job feel a bit too easy.

Chef

Chef is another veteran player in the infrastructure configuration game. Like Puppet, Chef provides its own DSL to help you enforce everything from configuration policies to continuous delivery of production code. For Chef Automate users (Chef’s commercial platform), you can automate the management of your self-hosted AWS-based infrastructure on an hourly basis or use AWS Opswork for Chef Automate.

With Chef Automate you can expect critical features like detailed compliance management, high availability, and GUI-based workflow pipeline creation.

Major integrations include AWS, Microsoft Azure Cloud Computing, VMware, and Google Cloud Computing.

Chef is a solid choice if compliance management is what you need.

Kubernetes

Originally developed by Google, Kubernetes is a container orchestration platform for automating the deployment, scaling, and management of containerized applications. In fact, it’s established itself as the defacto standard for container orchestration and is the flagship project of the Cloud Native Computing Foundation, backed by key players like Google, AWS, Microsoft, IBM, Intel, Cisco, and RedHat.

While it’s by no means an actual infrastructure configuration management tool, Kubernetes makes it easy to deploy and operate applications based on a microservice architecture for almost any cloud. It does so by creating an abstraction layer on top of a group of hostsso that development teams can deploy their applications and let Kubernetes manage things like controlling resource consumption by application or team, evenly spread application loads across their host infrastructure, and automatically load balance requests across the different instances of an application.

Thinking about adopting containers and a microservices architecture? Many suspect that Kubernetes may one day make traditional configuration management tools completely obsolete.

Terraform

Another aspect of infrastructure management is the idea of “infrastructure as code.” The Big 3 all claim this as a central philosophy, and Terraform is no different. Put simply, Terraform is an open source tool that you use to write declarative configuration files to create and modify infrastructure, but it’s not exactly a “configuration automation tool.”

If you used the company’s commercial product Terraform Enterprise in a cloud-based workflow (in AWS, for example), you’d write modules that are version-controlled configurations declaring the creation or modification of high-level resources, such as Amazon EC2 instances or Amazon Relational Database Service (RDS) resources. Terraform can help you automatically configure these resources with the aid of extensive resource graphing and execution plans. But you’ll still likely need a configuration management tool like Puppet or Chef to help you automate the setup and execution of the software on those resources.

Major integrations for Terraform include AWS, Google Cloud Platform, Microsoft Azure Cloud Computing, and Oracle Cloud.

Terraform takes “infrastructure as code” pretty seriously. You’re gonna get exactly what you expect here-strong, stable declarative configurations.

Google Cloud Deployment Manager

If you plan to build your cloud infrastructure with Google Cloud Computing, check out Cloud Deployment Manager. Here you can automate the configuration and deployment of your Google cloud with parallel, repeatable deployments and template-driven configurations. Cloud Deployment Manager provides a rich set of tools from CLIs and APIs to GUIs for managing all phases of your infrastructure’s configuration and management, from resource creation to deletion.

Microsoft Azure Automation

Azure Automation delivers a cloud-based automation and configuration service that provides consistent management across Azure and non-Azure environments. It consists of process automation, update management, and configuration features designed to help you reduce errors and cut the time spent on your infrastructure deployments. Azure Automation also provides automated control over maintenance and compliance runs.

Best of all, it’s not just for Windows! With Azure Automation, you get heterogenous deployments for Windows or Linux hosts using automation that you trigger with PowerShell or Python runbooks.

Microsoft is clearly showing its dedication to the modern DevOps practitioner. If you need to a run a diverse set of operating systems, Azure could be a great way to roll.

Cisco Intelligent Automation for Cloud

Cisco provides a number of cloud offerings, from private to public to hybrid solutions. Alongside these offerings, Cisco Intelligent Automation for Cloud gives everything from infrastructure-as-a-service (IaaS) to hands-on provisioning and management of instances running in the Cisco cloud or in other cloud environments, including AWS, OpenStack, and VMware.

Top features include a self-service portal for users of your cloud, multi-tenancy, and network service automation. Though clearly created with Cisco’s own cloud infrastructure offerings in mind, Cisco Intelligent Automation for Cloud benefits from being able to extend the automation tooling into other ecosystems.

Some pretty great features include a self-service portal for users of your cloud, multi-tenancy, and network service automation.

Cisco is a proven, stable giant and it looks like its automation services are perfect for those needing a one-stop full-service provider.

SaltStack

Originally an open source project like Puppet and Chef, Saltstack has also joined the enterprise sphere, with a big focus on automating security compliance. Like Ansible, SaltStack can be run agentless (but you can also run an agent if your workflows require it).

If you’re interested in moving to the cloud, SaltStack provides an interface for interacting with cloud providers called Salt Cloud, so you can use Salt to configure and manage all aspects of your cloud-based infrastructure.

Key capabilities of SaltStack include agentless node management and exceptional security compliance tooling. It also has major cloud integrations with AWS, Microsoft Azure cloud computing, VMware, Rackspace, Digital Ocean, OpenStack, and Google Cloud Computing.

Security compliance is seemingly a huge deal these days, so if this is a concern, maybe SaltStack is the way you want to go.

VMware vCenter Configuration Manager (VCM)

This small slice of the VMware world helps you configure and maintain your VMware cloud environments (running on vendors like AWS and RackSpace) so they meet your operational, security, and compliance requirements.

VCM gives you a central location to control configuration of your VMware-based infrastructure, whether it’s running on Windows, Linux, or Unix operating systems. You’ll also have a selection of VMware integrations at your fingertips—useful to help keep track of configuration data, change data, networking configurations, and compliance policies using a number of VMware tools, including vCenter, vCloud Director, and VMware vCloud Networking and Security.

CFEngine

CFEngine is a classic configuration management tool that’s long been used to automate IT infrastructures in all sizes of enterprises. Unlike tools such as Puppet that require a central management server, CFEngine relies on “autonomous agents” that run every five minutes to enforce their hosts’ configurations. Impressively, CFEngine lets you manage up to 5,000 hosts per management server.

CFEngine integrates with your Amazon EC2 infrastructure.

If you’re looking for stability and scale, check out CFEngine.

Foreman

If you need a lightweight tool to manage the full lifecycle of your servers, from bare metal to provisioning to orchestration, the open source Foreman project can help. However, note that Foreman relies on a fairly deep integration with open source Puppet for configuration management of your nodes, but it also boasts plugin support with Chef, Ansible, and Salt for other management aspects.

Its dedicated open source community maintains an extensive plugin library. You can provision cloud instances with Foreman on major providers such as Amazon EC2, Google Cloud Computing, OpenStack, and VMware.

Foreman is definitely one of the best options for teams building open source software.

Conclusion

Every infrastructure automation tool has its strengths, weaknesses, and learning curves. In choosing a tool, you’ll want to find the one that best matches the needs of your project and the needs of your teams. Cloud-vendor built tools may provide the easiest way to get the ball rolling as you start your cloud migration, especially if a “one-stop shop” is what you’re looking for.

Good news for cloud security experts: the AWS Certified Security — Specialty exam is here. This new exam allows experienced cloud security professionals to demonstrate and validate their knowledge of how to secure the AWS platform.

About the exam

The security exam covers incident response, logging and monitoring, infrastructure security, identity and access management, and data protection. The exam is open to anyone who currently holds a Cloud Practitioner or Associate-level certification. We recommend candidates have five years of IT security experience designing and implementing security solutions, and at least two years of hands-on experience securing AWS workloads.

The exam validates your understanding of:

Specialized data classifications and AWS data protection mechanisms

Data encryption methods and AWS mechanisms to implement them

Secure Internet protocols and AWS mechanisms to implement them

AWS security services and features of services to provide a secure production environment

Making tradeoff decisions with regard to cost, security, and deployment complexity given a set of application requirements

Security operations and risk

How to prepare

We have training and other resources to help you prepare for the exam.

AWS Training that includes:

Advanced Architecting on AWS classroom training

Security Operations on AWS classroom training

AWS Digital Training focused on security services and topics, such as:

AWS Security Fundamentals

Authentication and Authorization with AWS Identify and Access Management

AWS Shared Responsibility Model

AWS Well-Architected Training

Additional Resources

Security documentation

Compliance resources

Learn more and register here, and please contact us if you have questions about exam registration.

It’s a new year yet the same old story. Lots of big-name brands have already been afflicted by major system failures due to ransomware, overloads, and technical glitches.

It seems that “preventing system failure” was not a common new year’s resolution.

Completely preventing outages might be difficult for many companies, particularly those experiencing rapid growth or unpredictable demand surges. But widespread system failures are always a surprise because, put simply, we should know better by now.  

The first three months of 2018 witnessed more problems suffered by repeat offenders in the finance and social media industries. They caused a lot of grief, and in some cases tangible financial losses. The nightmare of actual and potential malware attacks also affected some major players – we should expect to hear about more of these incidents as “Meltdown” and “Spectre” work their way into our vocabulary. Finally, the new year was disappointing for some, when pastimes like visiting relatives and watching the Super Bowl were hampered by technical issues.

Related: CloudEndure Infrastructure Calculator allows at-a-glance comparison of disaster recovery infrastructure costs

Check out our list of the top nine Q1 outages of 2018.

1. Twitter DOWN – Micro blogging site not working for THOUSANDS of users

When: January 18 and 20, 2018

Duration: 2 hours + 1 day

What Happened: Starting as a relatively short outage on January 18, Twitter experienced a day-long series of interruptions on January 20. Not good news for Twitter, which saw other crises only a short while later. In mid-February, Twitter de-shelved its infamous app for Apple Macintosh computers after a long and troubled history dating back to 2011. Only a few days afterwards, it was announced that some Twitter trolls were tweeting a special character that causes continuing Twitter app crashes on iPhones, iPads, and Macs.

Twitter went down for about 20 minutes and I couldn’t even complain about it on Twitter.

— Jordan Coombe (@Jordan_Coombe) January 18, 2018

2. Facebook and Instagram are DOWN: Massive outage plunges the world into social media darkness

When: Mid-end February, 2018

Duration: Intermittent

What Happened: Although not as noteworthy as Cambridge Analytica, Q1 2018 wasn’t Facebook’s finest period. Both January and February saw daily outages, particularly mobile app crashes. Problems extended to Instagram as well, which is owned by Facebook. These issues were global in nature and ranged from total blackout to login failure. Ironically, many users turned to Twitter as a way to express their outrage – while Twitter experienced various crashes of its own.

This just happened. People be panicking in 3… 2… 1… #FacebookDown pic.twitter.com/n0q2SbmyE0

— John Santillana (@profinblack) February 22, 2018

3. Allscripts recovering from ransomware attack that has kept key tools offline

When: January 18-23, 2018

Duration: 6 days

What Happened: The SamSam ransomware virus struck again, this time at Allscripts, a health records company that saw its data centers locked out. Rather than pay the ransom, Allscripts called in experts from Microsoft and Cisco to help the company restore its systems, using backups and other methods. SamSam has a penchant for hitting healthcare firms, such as Hancock Health Hospital in Greenfield, Indiana, which actually chose to pay 4 BTC—amounting to $55,000—rather than the more expensive option of system restoration. SamSam attacks have collected approximately $850,000 since appearing in 2015.

Yes, 10 days after being hit with #SamSam and @Allscripts still has a 2003 server on the internet with open RDP. They clearly don’t give two shits about protecting their client base

https://t.co/HLTVw5Ptei … @HealthITNews @healthinfosec

— Reggie (@Ring0x0) January 27, 2018

  4. Fortnite downtime blamed on patches for Meltdown vulnerability

When: January 5, 2018

Duration: TBD

What Happened: To their credit, at least they are being honest about it. Epic Games, which develops and publishes Fortnite, announced that users may experience disruptions as the company implements patches to deal with the Meltdown problem. They have no choice but to issue Meltdown patches, otherwise their systems will be at risk for serious attacks. Meltdown is a vulnerability present in most CPUs manufactured since 1995, and allows extraction of sensitive data by attackers. It has only recently been identified, and presents a huge challenge for system security and stability.

@Fortnite The servers are down. Too much people trying to play but they cant because they are trying to do the new LTM. Plz fix this , thx

— Yaidan Chirino (@ChirinoJade) January 5, 2018

5. Uber outage yields complaints throughout the US

When: February 8, 2018

Duration: 2 hours

What Happened: Both drivers and riders were left stranded as Uber’s system broke down for a couple of hours. Various major U.S. cities were among those affected. To Uber’s credit (and probable exhaustion), complaints were handled on an individual basis through Twitter, notifying customers when the failure was resolved. Unfortunately, this is only the latest in a series of problems being recently experienced by the ride-sharing company.

@Uber_Support I keep getting this message when trying to schedule a ride. I have no outstanding payments and my payment options are all up to date. Please help. pic.twitter.com/hiJSQPz9JM

— Greg Boysen

(@GregBoysen) February 7, 2018

6.  US Customs computers outage causes delays for airport travelers

When: January 2, 2018

Duration: 2 hours

What Happened: The computer systems used by the U.S. Customs service failed only a day after New Year’s, meaning long lines for thousands of holiday travelers going through passport control. Several major airports were disrupted, including Dallas, Miami, San Francisco, Denver, and JFK. Luckily, no security breaches were involved, and the system was back online after a couple of hours. Still, it was no small inconvenience for tired vacationers.

What a nightmare at Miami’s airport. Passport system is down. @WPTV pic.twitter.com/QL17jSlFCP

— Chris Stewart (@CStewartTheNow) January 2, 2018

7.  Hulu Says Super Bowl Live-Streaming Outage Was Caused by Program-Extension Glitch

When: February 4, 2018

Duration: Less than an hour

What Happened: It was only a few minutes, but what a few minutes! NFL fans across the U.S. were shut out of the final plays of Super Bowl LII as Hulu’s video feed went down. Hulu did not disclose the number of affected subscribers and restored service within 45 minutes. The company blamed the failure on the fact that the game went longer than expected, and issued an apology.

@hulu_support no service :’( this is the worst way to be sick

— indigo (@indigogurt) February 3, 2018

8. Broker websites including Fidelity report outages during wild trading in US markets 

When: Feb 6, 2018

Duration: 1 day

What Happened: Numerous online stock trading websites experienced failures or considerable slowdowns as a massive transaction volume hit the markets. It took only half an hour to move the Dow Jones Industrial Average into positive territory after a record-setting drop the previous day. But as a result, trading firm giants such as Fidelity, T. Rowe Price, Bank of America, and TD Ameritrade provided less than optimal service. Sound familiar? Our previous outages report included Fidelity having similar issues.

Do not be so quick to move @Fidelity cost me hundreds today by not letting me trade SPXW between 3:10 and 3:24 EST.

— Anton (@tradintony) February 5, 2018

9. Cryptocurrency exchange Kraken is live after 2-day outage

When: January 13, 2018

Duration: 2 days

What Happened: Kraken is one of the world’s biggest cryptocurrency exchanges. On January 10, it announced that it would be offline for two hours for a software update, but service did not resume on time. In an industry where outages often mean hacking attacks, Kraken clients started to panic. When the website finally came back up on January 13th, some functions, including withdrawals, were still not available. Although the company apologized by eliminating trading fees for the rest of the month, some users were still unimpressed.

If the Kraken Exchange isn’t working perfectly when I wake up tomorrow morning, I am calling the FBI to request that they get involved in this situation. Your recent status update is unprofessional and shocking. PS – I am 25+ year lawyer. #kraken @krakensupport @krakenfx

— Clay Crawford (@Crawfordtx) January 12, 2018

Using the AWS Cloud for Your next Unity 3D Game ☞ https://medium.com/aws-activate-startup-blog/using-the-aws-cloud-for-your-next-unity-3d-game-c4e758bd71ab

The Greengrass API is a pile of spare parts with no wiring instructions — so here’s a map, an explanation, and some code

AWS Greengrass is a great technology. If you’re reading this, you likely already think so too. If you don’t — check out re:Invent keynote and AWS Greengrass intro, and you’ll come back convinced and inspired to hack.

To master Greengrass beyond the tutorials, to define and deploy setups in automated, reliable, repeatable way, one must hit the AWS API or CLI — we long live in the bright DevOps world.

There is a big problem here: while AWS documentation on Greengrass lists individual calls, it gives no clue on where to start. There is no map to show how to wire the calls together. All parts are in place, but the assembly manual is missing. Or, was missing — until this post.

Getting Started

I’ll begin with the high level: concept definitions, a map of the model, some theory on how things work … but my millennial readers are eager to learn by doing, so let’s get started with some working code. No worries, you’ll still find the map and concepts below.

When you click a single “Create Group” button in the AWS console to create Greengrass Core, the code provided below is what happens bend the scenes. It’s quite a lot … 7 calls across 3 AWS services — 5 entities created explicitly, 2 implicitly.

As a bonus, get this code in a

Jupyter Notebook for your convenience and immediate gratification!

Creating the group is just the beginning — you’ll still need to:

create Lambda functions with AWS Lambda

register them with IoT via Lambda definitions

define resources for your Lambdas to access

configure loggers and register devices

setup MQTT subscriptions for every point-to-point communication

deploy the whole shebang to a Greengrass core

And by the way, all of this must be properly installed and configured, carry the right certificates, and run on your edge device. If it sounds a bit complex, it is because it is a bit complex. Time to elevate to the concepts and get oriented.

The Lifecycle Workflow

First, let’s review the steps of a Greengrass operation lifecycle workflow.

Create Greengrass group definition in AWS IoT — a number of calls to AWS API to create and connect all necessary entities.

Setup Greengrass core “on the edge” — configure a box Raspberry Pi or other compatible device, or VM / Docker for dev & testing. Download and install a proper version of greengrass, put certificates in place, adjust `config.json`, and launch the Greengrass daemon.

Deploy — tell AWS to push Greengrass group definition to the Greengrass Core runtime(s).

Clean up — the steps 1–3 produce a slew of artifacts that would pollute your AWS account if not properly recycled.

The Model

Next let’s understand the model. The group definition — step 1 above — is by far the most complex. To help you navigate it, I created a “Greengrass Entity Map”. While the map is not a topologically precise representation of AWS API, it would help you grasp the model and not be lost.

Greengrass is intertwined with other AWS services — most notably IoT, Lambda, and IAM & security which are color-coded on the map. Take a look at the map. Spot the objects created by the code above. Explore the rest. Enjoy!

Please help make this map better — report errors and omissions on the map here.

The LoggerDefinition and ResourceDefinition blocks are not shown on the map to reduce clutter — they are relatively straightforward so you can extrapolate now that you see the pattern.

Greengrass is conceptually a part of AWS IoT, and visually it’s a section of IoT in AWS console. But at the API level it is a separate service with distinct model — quite different from IoT in the concept, conventions, and even naming.

The Entities

In Greengrass, each entity is versioned and immutable. Any modification is done via updating an entity with a newly created version. Versions carry all the data and references to the other AWS services.

Group Version The focal point of the model is a Group Version. A group manifests in the AWS console only once a Group Version is created. But to create a Group Version, you must first create a pinch of other entities and supply them to create_group_version call.

Greengrass Core The Greengrass Core has dual nature: on the IoT side, it as a “thing”, or “device” for connection and communications, and is represented by IoT “thing” in the IoT registry, along with attached certificates, role and policies. On the Greengrass side, it is exposed as a CoreDefinition/Version.

Lambda Functions Lambda functions are first created in AWS Lambda, and linked to Greengrass via FunctionDefinition/Version. It also adds some extra Greengrass-specific Lambda parameters — like pinned flag to make Lambda long running, device access policies, or extra environment variables.

To be linked, Lambdas must be published, and shall be referred by a qualified ARN — an ARN with a version or an alias (recommended). I wish AWS API doc told me about this— it doesn’t, and API throws a puzzling “functions definition is invalid or corrupted” message if you supply an unqualified ARN as FunctionArn.

Subscriptions Subscriptions are straightforward but too verbose to define: I find it irritating as it takes a bunch of them to define all communication between devices, lambdas, and cloud. How to deal with it? See “file-based approach to Greengrass setup” down below.

Device Definition Device Definition represent devices connected to the core as links to IoT Things — these Things must be set up in AWS IoT. Consider using ELF to quickly simulate a device for you dev environment. Logger Definition tells Greengrass core what to log locally and what to send to CloudWatch. Resource Definitions are there to define Lambda access to resources of Greengrass core device group-wide, to attach to Lambda Function Definitions.

Oh, and did you notice Machine Learning resources in Greengrass AWS Console now that

AWS ML Inference is generally available?

Enough said about the map: explore it, track and find the correspondent AWS API calls to create and connect the entities. I considered putting the exact methods on the map but decided to favor aesthetics, leaving you some space and joy of discovery.

Deploying Greengrass

Finally, a word on file-based approach to Greengrass deployment. As I played with Greengrass, I wanted — but missed—the three things I am so used to enjoy with Ansible, Terraform, or Serverless framework:

File-based Greengrass group definition

One-command to create, deploy, and clean things up

Simple, representable, repeatable dev boilerplate with Greengrass Core on a VM (Docker? even better!)

I missed it, so I wrote one. Please welcome greengo — a simple file based Greengrass configuration tool.

Greengo — a simple Greengrass configuration tool

Take it as your Greengrass dev boilerplate — adjust greengo.yaml to your liking and hit greengo create. Or use is as a cheat-sheet to find out how to call the right boto3 methods in the right order with the right parameters, as you track the chains on the map above.

That’s it. I hope that the map above, the code examples, the explanations and greengo tool/cheat-sheet will fill out the blanks in AWS doc and help you operate Greengrass in automated, repeatable way, DevOps style.

Happy green-grassing!

Hey, it’s HighScalability time:

Bathroom tile? Grandma’s needlepoint? Nope. It’s a diagram of the dark web. Looks surprisingly like a tumor.

On his portfolio site, Jeremy Carson (creative director at Saatchi in L.A.) talks about a challenge he set for himself when he was a student — to improve the quality of his work by doing an ad a day and posting it publicly. Though the process was neither easy nor flattering, he quickly saw his work improve. And now, Jeremy has built a page to help you guys take up the challenge for yourselves. He sets out the rules of the game, and he even has a random brand generator to help you find your client for each day’s ad. Jeremy lays it all out for you here.